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.
This section discusses:
Trigger uses.
Trigger table data.
Trigger generation.
Managing used or obsolete triggers.
Defining triggers manually.
In Absence Management, 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 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 absence type for days reported changes and the change goes back to a prior calendar. The absence data must be reprocessed to ensure that the payee receives the right amount of absence days for the correct type of absence.
Segmentation
A segmentation trigger tells the system to segment all or a subset of absence elements in an absence run in response to a change in payee data.
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.
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.
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. |
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 absences, 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 the Trigger Status for Iterative Triggers.
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 |
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. |
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 periods to process retroactively (for example, a retro trigger with an effective date of January 1, 2006 tells the system to reprocess all calendars beginning with the January 2006 absence 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 trigger 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 trigger 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 trigger 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 absences, 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.
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. |
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 period (for example, a segmentation trigger with an effective date of June 15 tells the system to divide the June 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 payee-level or at the payee-job (EMPL_RCD) level trigger. Instructs the system to process for one job only or for all jobs. |
CAL_RUN_ID |
Identifies the first calendar group ID that uses a segmentation trigger. If the segmentation trigger is reused because of retroactivity, the calendar group ID isn't updated. |
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 trigger 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 trigger 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 trigger is defined at the record level only. |
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.
Note. You can view the trigger source data stored in this table on the Segmentation page.
See Viewing, Adding, or Canceling Segmentation Triggers.
This section discusses the concept of trigger effective date types (Trigger Effdt Type) 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.
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.
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.
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 absence 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 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.
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.
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 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 Viewing, Adding, or Canceling Segmentation Triggers.
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).
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.
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.
The Absence Management 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 absence 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 Absence Management system addresses the problem of unnecessary segmentation triggers 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 ):
Data Change |
Record Trigger Level |
Field – Non Value Based Trigger Level |
Field – Value Based Trigger Level |
Effective, Begin, or End Date Correction |
Yes |
Yes |
Yes |
Field Value Correction |
No |
Yes |
Yes |
Row Deletion |
Yes |
Yes |
Yes |
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 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.
User Action |
Field Change |
Effdt/Effseq |
Trigger Action |
Trigger Effdt |
Source Field Value |
Trigger Event ID |
Existing Row |
DTA |
10/20/05 |
Insert |
10/20/05 |
DTA |
Event 1 |
Existing Row |
TER |
11/15/05 |
Insert |
11/15/05 |
TER |
Event 1 |
Correction |
TER |
11/20/05 |
Delete |
11/15/05 |
TER |
Event 1 |
Insert |
11/20/05 |
TER |
Event 1 |
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:
User Action |
Field Change |
Effdt/Effseq |
Trigger Action |
Trigger Effdt |
Source Field Value |
Trigger Event ID |
Existing Row |
PAY |
01/01/05 |
Insert |
01/01/05 |
PAY |
Event 1 |
Existing Row |
TER |
10/20/05 |
Insert |
10/20/05 |
TER |
Event 1 |
Existing Row |
DTA |
11/15/05 |
None |
TER |
Event 1 |
|
Correction |
DTA |
10/20/05 |
Delete |
10/20/05 |
TER |
Event 1 |
No Trigger |
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:
User Action |
Field Change |
Effdt/Effseq |
Trigger Action |
Trigger Effdt |
Source Field Value |
Trigger Event ID |
Existing Row |
PAY |
01/01/05 |
None |
DTA |
Event 1 |
|
Existing Row |
PAY |
07/01/05 |
None |
TER |
Event 1 |
|
Existing Row |
DTA |
01/01/06 |
Insert |
01/01/06 |
TER |
Event 1 |
Correction |
DTA |
07/01/05 |
Delete |
No trigger to delete. |
TER |
Event 1 |
Insert |
07/01/05 |
|||||
Delete |
01/01/06 |
|||||
No Trigger |
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.
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.
Note. Iterative triggers can not be added manually.
See Pages Used to Manage Triggers and Enter Triggers Manually.
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
Defining Retroactive Processing
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.
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:
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.
Select the Add a New Value tab.
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.
Click the Add button.
The Trigger Definitions page appears.
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 result in trigger generation by selecting the Dependent on Field Value Action check box for a specific field and specifying the values that trigger iterative processing.
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:
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.
Select the Add a New Value tab.
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.
Click the Add button.
The Trigger Definitions page appears.
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.
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 the 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 result in trigger generation by selecting the Dependent on Field Value Action check box for a specific field, click the List Field Values link, and specifying the values that trigger retro processing.
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 retro 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 Absence Management, you can set up segmentation triggers for effective-dated records. 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:
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.
Select the Add a New Value tab.
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.
Click the Add button.
The Trigger Definitions page appears.
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 result in trigger generation by selecting the Dependent on Field Value Action check box for a specific field, click the List Field Values link, and specifying the values that should result in trigger generation.
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 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.
Page Name |
Definition Name |
Navigation |
Usage |
GP_TRGR_SETUP |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions, Trigger Definitions |
Define iterative, segmentation, and retroactive triggers. To create a retroactive or segmentation trigger, first define the appropriate event ID on the Retro Event Definition page or Segmentation Event Definition page. |
|
GP_TRGR_SETUP_SEC |
Click the List Field Values link on the Trigger Definitions page. |
Indicate which field values initiate actions. |
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.
Country |
Specify the country for which you are defining the trigger. |
Record (Table) Name |
Displays the record (table) name that you selected to access this page. This record can stand alone or be part of the record and field combination that generates a trigger in response to an online data change. |
Trigger Type |
Displays the trigger type that you selected to access this page. Options are: Iterative, Retro, and Segmentation. |
Trigger Event ID |
For retro and segmentation triggers, specify the trigger event ID at the record level, the field level, or the field value level:
Note. Iterative triggers don't have trigger event definitions, because their only function is to process a payee in the current open calendar; therefore, the defined event is always the same. |
Trigger Status |
To activate the trigger definition, select Active. |
Trigger Level |
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 the 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 Field column in the List Fields With Trigger group box. You can further restrict the data changes that result in trigger generation by selecting the Dependent on Field Value Action check box for a specific field, click the List Field Values link, and specifying the values that should result in trigger generation. |
Primary Event ID |
Enter one of the event IDs defined on the Retro Event Definition page. The primary event ID functions as the default event ID when the trigger level is Field and 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). In this case, the system generates a retroactive trigger using the primary retroactive event ID. Note. The Primary Event ID field appears only when the trigger type is Retro and the trigger level is Field. |
Trigger Effdt Type |
This field displays one of the following values, based on the record specified in the Record (Table) Name field: Effective Date Begin-End Date Fixed Date Only retro triggers can have a trigger effdt type of Fixed Date. To generate retro triggers with a fixed trigger effective date, you must pass the date as a parameter to the generic PeopleCode function Generate_Triggers. The system generates only one trigger regardless of the number of data changes. |
List Fields with Trigger
If you selectField in the Trigger Level field, the List Fields With Trigger group box becomes available.
Field Name |
Enter the name of the field that you want to make sensitive to data changes. |
Dependent on Field Value |
Select this check box to indicate that the fields that you've defined as sensitive to data changes are dependent on specific field values. In this case, only changes to the values you specify on the Trigger Definition - Field Values page will trigger a system action. This enables you to limit the kinds of changes that cause iterative, retroactive, or segmentation processing. |
List Field Values |
This link becomes available when you select the Dependent on Field Value check box. Click to access the Trigger Definitions - Field Values page, where you can list the field values that trigger an action. |
Trigger Event ID |
This field is required when the trigger level is Field and Dependent on Field Value is cleared. Based on the type of trigger you are defining, enter an event ID that you defined on either the Retro Event Definition page or the Segmentation Event Definition page. Note. This field is not used with iterative triggers. |
Access the Trigger Definitions - Field Values page (click the List Field Values link on the Trigger Definitions page).
Field Values
Sequence |
Enter a sequence number, which the system needs to uniquely identify the field values and distinguish them from other rows of data that you might set up. |
Numeric Value |
If the record and field combination stores numeric values, this field is available for entry. Enter the value that triggers a system action. |
Character Value |
If the record and field combination stores character values, this field is available for entry. Enter the value that triggers a system action. |
Date Value |
If the record and field combination stores date values, this field is available for entry. Enter the value that triggers a system action. |
Trigger Event ID |
This field is required when the trigger level is Field and Dependent on Field Value is selected. Based on the type of trigger you are defining, enter an event ID that you defined on either the Retro Event Definition page or the Segmentation Event Definition page. Note. This field is not used with iterative triggers. |
Offset Days |
This field is available only when the trigger type is Retro. Enter a positive or negative number to increase or decrease the retro trigger effective date relative to the date of a database change. For example, if you enter -1 in the Offset Days field for one of the values listed in the Field Values group box, and you retroactively enter that value into the database with an effective date of January 1, 2000, the system automatically adjusts the trigger effective date to December 31, 1999 (one day earlier). The system then processes pay periods going back to December 1999 rather than January 2000. |
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.
Do Not Trigger |
This option is selected by default because the system assumes that triggers should be generated only when there is a match between values actually entered in the database and the field values that you identify on the Trigger Definitions – Field Values page. |
Trigger |
When you select this option, the Trigger Event ID field becomes available for entry. |
Trigger Event ID |
Enter a default trigger event ID to use to process field values that are not linked to a trigger event ID on the Trigger Definitions – Field Values page. |
Example: Using Offset Days with Retro Triggers
In 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 effective date of the termination row in JOB. This can create problems when the termination effective date is equal to the 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 the JOB record on February 1 after processing and closing the January calendar. In this situation, the system generates a retro 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
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.
Declare the function that generates triggers:
Declare Function Generate_Triggers PeopleCode FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula;
Declare a local date variable as:
Local date &L_DT;
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's invoked. The parameters are:
&P_EMPLID
Indicates the EMPLID for which the triggers are to be generated. Use field EMPLID for &P_EMPLID.
&P_FIXED_DT
Holds the value of the trigger effective date for records with a Trigger Effdt Type of Fixed Date. It is ignored for records with a Trigger Effdt 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 case of the Fixed Date type of triggers. Examples are the positive input records, the Manual Positive Input table (GP_PI_MNL_DATA) and the Manual Positive Input Supporting Element Override table (GP_PI_MNL_SOVR).
Note. You can enter PeopleCode that can invoke the function only if certain conditions are met, as discussed in example 2 below.
The following example is from PeopleCode that's delivered with the database. The example shows changes necessary for any additional records that are to generate triggers.
Example: 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 Effdt Type for the Payee Supporting Element Override table (GP_PYE_SOVR) is not Fixed Date.
See Also
Reviewing PeopleSoft Delivered Triggers
This section discusses how to:
View, add, or cancel segmentation triggers.
View, add, or cancel retroactive triggers.
View the trigger status for iterative triggers.
View iterative triggers by calendar group ID.
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 retro 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.
Page Name |
Definition Name |
Navigation |
Usage |
GP_TRIGGER_SEG |
Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Segmentation |
View, add, or cancel segmentation triggers by payee. A segmentation trigger must be active to be viewed or managed on this page. |
|
GP_TRIGGER_RTO |
Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Retro |
View, add, or cancel retroactive triggers by payee. A retroactive trigger must be unprocessed to be viewed or managed on this page. |
|
GP_TRIGGER_ITER |
Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Iterative |
View iterative triggers by payee. An iterative trigger must be unprocessed to be viewed on this page. |
|
GP_TRGRITER_CALRUN |
Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Iterative Triggers, Review Iterative Triggers |
View iterative triggers by calendar group ID. An iterative trigger must be unprocessed to be viewed on this page. |
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.
Country |
Displays the country to which the trigger applies. Enter a country code if you are creating a trigger manually. |
Effective Date |
Displays the trigger effective date in relation to which a pay period or the elements in a pay period are segmented. Enter a trigger effective date if you are defining a trigger manually. |
Event ID |
Displays the event ID, which tells the system what type of segmentation to use to process segmentation events and which elements to segment (in the case of element segmentation). The event IDs displayed here are those that you defined on the Segmentation Event Definition page. Enter an event ID if you are creating a trigger manually. |
Description |
Displays a description of the trigger event ID that you defined on the Segmentation Event Definition page. |
Trigger Level |
Options are: Payee: If the trigger level is Payee, the system segments pay elements for all jobs belonging to the payee. Job: If the trigger level is Job, the system segments pay elements for the job identified by the employee record number in the Empl Rcd # field. |
Empl Rcd# (employee record number) |
Displays the employee record number (job) affected by the segmentation trigger. If you are defining triggers manually, select the employee record number (job) for which you want to create a trigger. If the trigger level is Payee, the system automatically sets the value of this field to 0. |
Trigger Status |
Select a trigger status. Options are: Active: By default, the value of this field is Active. Canceled: Select to cancel an active segmentation trigger. When you select Canceled, the trigger disappears when you click Save and reenter the page. |
Source/TS
Select the Source/TS tab.
Use the Source/TS 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:
Trigger Level |
Information Displayed |
Record |
Record Information |
Field, Non-Value Based |
Record and Field Information |
Field, Value-Based |
Record and Field Information |
Country |
Same as the Country field on the Event ID tab. |
Effective Date |
Same as the Effective Date field on the Event ID tab. |
Event ID |
Same as the Event ID field on the Event ID tab. |
Trigger Source |
Displays one of the following values:
|
Source Record |
View the record that is the source of a trigger. For manually defined triggers, this field is blank. |
Field Name |
View the field that is the source of the trigger. For manually defined triggers, this field is blank. |
Timestamp |
Displays the day and time the trigger was created. For manually defined triggers, this field is blank. |
Value
Select the Value tab.
Use the Value 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:
Trigger Level |
Information Displayed |
Field, Non-Value Based |
Field Value Information For segmentation triggers generated from effective-dated records, the system displays the character, date, or numeric value that triggers segmentation. |
Field, Value-Based |
Field Value Information For segmentation triggers generated from effective-dated records, the system displays the character, date, or numeric value that triggers segmentation. |
Country |
Same as the Country field on the Event ID and Source/TS tabs. |
Effective Date |
Same as the Effective Date field on the Event ID and Source/TS tabs. |
Event ID |
Same as the Event ID field on the Event ID and Source/TS tabs. |
Character Value |
Displays the character value that generates a trigger. |
Numeric Value |
Displays the numeric value that generates a trigger. |
Date Value |
Displays the date value that generates a trigger. |
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 that you specify 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 which 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's important to understand the potential consequences of creating manual triggers. Because they aren't linked to a specific data change, you might segment periods and elements where nothing has changed.
Updating and Canceling Segmentation Triggers
For automatically and manually generated rows of trigger data:
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
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.
Country |
Displays the country to which the trigger applies. Enter a country code if you are creating a trigger manually. |
Trigger Effective Date |
Displays the trigger effective date. The system uses this date to determine which pay periods to recalculate. Enter a trigger effective date if you are defining a trigger manually. |
Event ID |
Displays the event ID, which tells the system what retro event definition to use to process the retroactive data. The event IDs displayed here are those that you defined on the Retro Event Definition page. Enter an event ID if you are creating a trigger manually. |
Description |
Displays a description of the trigger event ID that you defined on the Retro Event Definition page. |
Trigger Status |
Select a trigger status. Options are: Unprocessed: By default, the value of this field is Unprocessed. Canceled: Select to cancel a retro trigger. When you select Canceled, the trigger disappears when you click Save and reenter the page. |
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:
Trigger Level |
Information Displayed |
Record |
Record Information |
Field, Non-Value Based |
Record and Field Information |
Field, Value-Based |
Record and Field Information |
Country |
Same as the Country field on the Event ID tab. |
Effective Date |
Same as the Effective Date field on the Event ID tab. |
Event ID |
Same as the Event ID field on the Event ID tab. |
Trigger Source |
Displays one of the following values:
|
Trigger Tag |
If a trigger is utility-generated, this field displays the source of the trigger. |
Source Record |
View the record that is the source of a trigger. For manually defined triggers, this field is blank. |
Field Name |
View the field that is the source of the trigger. For manually defined triggers, this field is blank. |
Value
Select the Value tab.
Use the Value 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
Country |
Same as the Country field on the Event ID and Source tabs. |
Trigger Effective Date |
Same as the Trigger Effective Date field on the Event ID and Source tabs. |
Event ID |
Same as the Event ID field on the Event ID and Source tabs. |
Character Value |
Displays the character value that generates a trigger. |
Numeric Value |
Displays the numeric value that generates a trigger. |
Date Value |
Displays the date value that generates a trigger. |
Timestamp |
Displays the day and time the trigger was created. For manually defined triggers, this field is blank. |
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 previous 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.
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.
Country |
Displays the country to which the trigger applies. |
Calendar Group ID |
Identifies the calendar group in which the iterative trigger is processed. |
Trigger Status |
Select a trigger status. Options are: Unprocessed: By default, the value of this field is Unprocessed. Canceled: Select to cancel an iterative trigger. When you select Canceled, the trigger disappears when you click Save and reenter the page. |
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:
Trigger Level |
Information Displayed |
Record |
Record Information |
Field, Non-Value Based |
Record and Field Information |
Field, Value-Based |
Record and Field Information |
Country |
Same as the Country field on the Calendar Group tab. |
Calendar Group ID |
Same as the Calendar Group ID field on the Calendar Group tab. |
Trigger Source |
Displays one of the following values:
|
Source Record |
View the record that is the source of a trigger. |
Field Name |
View the field that is the source of a trigger. |
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
Country |
Same as the Country field on the Source tab. |
Calendar Group ID |
Same as the Calendar Group ID field on the Source tab. |
Character Value |
Displays the character value that generates a trigger. |
Numeric Value |
Displays the numeric value that generates a trigger. |
Date Value |
Displays the date value that generates a trigger. |
Timestamp |
Displays the day and time the trigger was created. |
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.
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.
EmplID |
Displays the EmplID of the payee associated with the iterative trigger. |
Name |
Displays the name of the payee associated with the iterative trigger. |
Trigger Status |
Select a trigger status. Options are: Unprocessed: By default, the value of this field is Unprocessed. Canceled: Select to cancel an iterative trigger. When you select Canceled, the trigger disappears when you click Save and reenter the page. |
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:
Trigger Level |
Information Displayed |
Record |
Record Information |
Field, Non-Value Based |
Record and Field Information |
Field, Value-Based |
Record and Field Information |
EmplID |
Same as the EmplID field on the Name tab. |
Name |
Same as the Name field on the Name tab. |
Trigger Source |
Displays one of the following values:
|
Record Name |
View the record that is the source of a trigger. |
Field Name |
View the field that is the source of a trigger. |
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
EmplID |
Same as the EmplID field on the Source tab. |
Name |
Same as the Name field on the Source tab. |
Character Value |
Displays the character value that generates a trigger. |
Numeric Value |
Displays the numeric value that generates a trigger. |
Date Value |
Displays the date value that generates a trigger. |
Timestamp |
Displays the day and time the trigger was created. |
To facilitate trigger generation, Absence Management 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. Absence Management 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 SavePostedit peoplecode.
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
GP_SEG_TRGR
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.