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.
Segmentation triggers with earning and deduction assignments.
Defining triggers manually.
In Global Payroll, the mechanism used to detect online data changes that should result in iterative, retroactive, or segmentation processing is called a trigger. To set up triggers, you select the database records and fields that you want to make sensitive to data changes such as pay increases, job location changes, and terminations; then, when the change occurs, the system writes a line of data to a table called a trigger table to tell the system how to process the change.
There are three types of triggers:
Iterative
An iterative trigger tells the system to process (or reprocess) a payee in the current open calendar, possibly because payee data has changed or the payee was placed in suspended mode during batch processing. The system generates only one iterative trigger per payee per open calendar group, regardless of the number of calendars in the calendar group. When data changes for the payee, the system (using online code) generates iterative triggers that enable the batch process to recalculate the payee, add the payee to the calendar run, or remove the payee from the calendar run.
Retroactive
A retroactive (or retro)trigger tells the system to reprocess previously calculated (closed) calendars. For example, this can occur when a payee's rate of pay changes and the change goes back to a prior calendar. The payroll data must be reprocessed to ensure that the payee receives the correct payment amounts.
Segmentation
A segmentation trigger tells the system to segment all or a subset of payroll elements in a pay run in response to a change in payee data.
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 earnings, and can be used to facilitate debugging or answer queries.
Note. You can view the trigger source data stored in this table on the Iterative page.
See Viewing or Changing the Trigger Status for Iterative Triggers.
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. |
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 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 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. |
When a segmentation trigger is generated by a data change, the system writes the employee ID, the effective date of the change (also called the trigger effective date), the country, and the associated event ID along with other information to the trigger table to facilitate retroactive processing by the batch code.
Among other things, this data tells the system:
Which payees to process.
The dates to use for the period segments or slices.
What type of segmentation to use and the elements to segment (in the case of element segmentation).
In addition, the system uses the RECNAME, FIELDNAME, TRGR_FLD_VAL_CHAR, TRGR_FLD_VAL_DT, TRGR_FLD_VAL_NUM, and TRGR_FLD_VAL_PIN fields to identify the source of a segmentation trigger (the record, field, and/or field value changes that generate a trigger). This information enables a clearer understanding of what causes segmentation of a payee's earnings, and can be used to facilitate debugging or answer queries.
Note. You can view the trigger source data stored in this table on the Segmentation page.
See Viewing, Adding, or Canceling Segmentation Triggers.
This section discusses the concept of trigger effective date types and trigger levels, and describes how and when the system generates triggers based on effective date types and trigger levels.
Effective Dates and Effective Date Types
All triggers except iterative triggers are stored in the trigger tables with their trigger effective dates (TRGR_EFFDT). These dates are based on—but are not necessarily identical to—the dates of the database changes that cause the triggers to be generated. In the PeopleSoft system, these database change dates are recorded in the following fields: Effective Date, Begin and End Date, and Fixed Date fields. Because of the central role played by these fields, retro and segmentation triggers can only be generated from dated records: retroactive triggers can only be defined for records with Effective or Begin and End Date fields, or records with Fixed Date fields; and segmentation triggers can only be defined for records with Effective Date fields, with one exception: the system can also generate segmentation triggers from the begin and end dated earning/deduction assignment record GP_PYE_OVRD.
Based on which date field is the source of the trigger effective date, every retro and segmentation trigger falls into one of the following effective date types:
Effective Date: Trigger date is based on an Effective Date field.
Begin/End Date: Trigger date is based on a Begin or End Date field.
Fixed Date: Trigger date is based on a fixed date that has been passed as a parameter to the generic PeopleCode function Generate_Triggers.
When the system processes retro and segmentation triggers, it uses the effective date type determine what date to use as the trigger effective date.
Note. Iterative triggers do not use the concept of trigger effective dates, since the change date is irrelevant to their function, which is to trigger the calculation or recalculation of the current pay run for a specific payee. They can be defined for non-effective-dated records as well as effective dated and begin and end dated records.
Trigger Levels
When you set up triggers in PeopleSoft Global Payroll, you must specify the level at which the system responds to database changes: you can set up the system to generate triggers in response to effective or begin and end dated changes to any field in a record (trigger level = Record), to all changes to a specific field in the record (trigger level = Field, Non Value Based), or only when a specific value is entered in the field (trigger level = Field, Value Based). The trigger level determines when and under what conditions the system generates triggers.
Rules for Iterative Triggers: Generating Triggers
Iterative triggers are generated only when an open calendar group exists; the calendar group must have been "Identified."
When the trigger level is Record, the system generates an iterative trigger if a row is added, changed, or deleted.
When the trigger level is Field, Non-Value-based, the system generates an iterative trigger if:
A row and the field are changed.
A row is added or deleted.
Note. For Field, Non-Value-based triggers, adding a row causes a trigger to be generated only if the field value changes.
When the trigger level is Field, Value-based, besides observing the rules for non-value-based triggers, the system generates an iterative trigger only if the value of the added, changed, or deleted row matches a value you specified earlier, or you have chosen to generate triggers even if no values match.
Rules for Retroactive Triggers: Setting Trigger Effective Dates and Generating Triggers
When Trigger Effective Date Type is Effective Date:
By default, if a row is added, the system uses the effective date as the trigger effective date.
Note. Although the default is to use the change date (the effective date of the added row) as the trigger effective date, you can modify effective dating of retro triggers on the Trigger Definitions – Field Values page so that the trigger date falls before or after the actual change date.
If a row is deleted, the system uses the initial effective date as the trigger effective date.
If a row is changed, the system uses the earlier of the initial effective date and the changed effective date as the trigger effective date.
The initial effective date is the effective date with which the row was loaded. The changed effective date is the effective date of the row at save time. If you haven't changed the effective date, it's the same as the initial effective date. If you've changed the effective date, it is different from the initial effective date.
When Trigger Effective Date Type is Begin/End Date:
By default, if a row is added, the system uses the begin date as the trigger effective date.
Note. Although the default is to use the change date (the begin date of the added row) as the trigger effective date, you can modify effective dating of retro triggers on the Trigger Definitions – Field Values page so that the trigger date falls before or after the actual change date.
If a row is deleted, the system uses the initial begin date as the trigger effective date.
If a row is changed and the end date is the only changed field, the system uses the earlier of the initial end date and changed end date as the trigger effective date; otherwise, the system uses the earlier of the initial begin date and the changed begin date as the trigger effective date.
The initial begin date is the begin date with which the row was loaded. The changed begin date is the begin date of the row at save time. If you haven't changed the begin date, it's the same as the initial begin date. If you've changed the begin date, it is different from the initial begin date.
The initial end date is the end date with which the row was loaded. The changed end date is the end date on the row at save time. If you haven't changed the end date, it's the same as the initial end date. If you've changed the end date, it's different from the initial end date.
Note. With absences, the system uses the begin date as the trigger effective date even if you change the end date. If an existing row is voided, and a new row is created, the system uses the begin date as the trigger effective date.
When Trigger Effective Date Type is Fixed Date, the trigger date is the date that you specify as a parameter in the PeopleCode function Generate_Triggers.
When Trigger Level is Record:
The system generates a retro trigger if a row is added, changed, or deleted.
If you change multiple rows, the earliest trigger date from all the changed rows is used as the trigger effective date.
When Trigger Level is Field, Non-Value-based:
If a row is added or deleted, the system finds the maximum effective-dated row that's earlier than the trigger date for the row.
If the field value differs between the prior row and the added or deleted row, the system generates a retroactive trigger.
If a row and the field value are changed, the system generates a retroactive trigger regardless of whether the effective date for that row is changed.
If a row and the effective date for that row are changed (assume the effective date before the change is the "old date" and that the effective date after the change is the "new date"):
If the field is changed, the system generates a retroactive trigger.
The system finds the row whose maximum effective date is less than the new date.
If the field value differs between the prior row and the changed row, a retroactive trigger is generated.
The system finds the row whose maximum effective date is less than the old date.
If the field value differs between the prior row and the changed row, a retroactive trigger is generated.
If a prior row isn't found, the added, changed, or deleted row is the first row in the buffer.
In this case, a retroactive trigger is generated with the primary event ID specified in the trigger definition.
When Trigger Level is Field, Value-based, besides observing the rules for non-value-based triggers, the system generates a retroactive trigger only if the value of the added, changed, or deleted row matches a value you specified earlier or you've chosen to generate a trigger even if no values match.
Rules for Segmentation Triggers: Setting Trigger Effective Dates and Generating Triggers
With the exception of the begin and end dated earning and deduction assignment record GP_PYE_OVRD, you can generate segmentation triggers only from records whose Trigger Effective Date Type is Effective Date.
See Segmentation Triggers with Earning and Deduction Assignments.
Segmentation triggers aren't generated for deleted rows.
When Trigger Effective Date Type is Effective Date:
If a row is added, the system use the effective date of the added row as the trigger effective date.
If a row is changed, the system uses the effective date of the change as the trigger effective date (not the initial effective date).
Note. The initial effective date is the effective date with which the row was loaded. The changed effective date is the effective date of the row at save time.
When Trigger Effective Date Type is Begin/End Date:
Note. The only begin and end dated record for which you can define segmentation triggers is the earning and deduction assignment record GP_PYE_OVRD
If a row is added, the system uses the begin date as the effective date of the initial trigger, and the end date + 1 as the effective date of the terminal trigger.
Note. When a segmentation trigger is generated from the begin and end dated record GP_PYE_OVRD, the system creates two triggers, each with a different trigger effective date—one based on the begin date, and another based on the end date. For example, assume that you assign a deduction to a payee with begin and end dates of June 10 and June 20, and that you process payrolls on a monthly calendar. The system creates a trigger with an effective date of June 10 (the initial trigger), and a second trigger with an effective date of June 21 (the terminal trigger with an effective date of end date + 1). Based on these trigger dates, the system divides the period into three segments: 1–10 June, 11–20 June, and 21–30 June.
If a row is changed and the end date is the only changed field, the system uses the changed end date + 1 as the new terminal trigger effective date. If a row is changed and the begin date is the only changed field, the system uses the changed begin date as the new initial trigger effective date.
The initial begin date is the begin date with which the row was loaded. The changed begin date is the begin date of the row at save time. If you haven't changed the begin date, it's the same as the initial begin date. If you've changed the begin date, it is different from the initial begin date.
The initial end date is the end date with which the row was loaded. The changed end date is the end date on the row at save time. If you haven't changed the end date, it's the same as the initial end date. If you've changed the end date, it's different from the initial end date.
When Trigger Level is Record, the system generates a segmentation trigger if a row is added or changed.
When Trigger Level is Field, Non-Value-based:
If a row is added or changed, the system finds the row whose maximum effective date is less than the added or changed row.
If the field value differs between the prior and current row, the system generates a segmentation trigger.
If a prior row cannot be found:
If the field value is changed, the system generates a segmentation trigger.
If it is a new row, the system generates a segmentation trigger for all specified fields.
When Trigger Level is Field, Value-based, besides observing the rules for non-value-based triggers, the system generates a segmentation trigger only if the value of the added or changed row matches a value you specified earlier or you have chosen to generate triggers even if no values match.
The Global Payroll system automatically marks retro and iterative triggers as used once they initiate the required processing so that they do not affect future calculations. In addition, you can manually cancel both iterative and retro triggers that have been created in error or that you do not want to impact payroll processing. By contrast, segmentation triggers are designed to remain active in the system, since if a segmentation event occurs during a calculation period, it should trigger segmentation every time the period is processed. However, there are times when segmentation events need to be modified or removed after they are entered in the system, either because they should not have been entered at all, the dates of the event were entered incorrectly, or other data was recorded incorrectly. The Global Payroll system addresses the problem of unnecessary triggers left by segmentation events by automatically deleting them in response to the following data changes at each of the three trigger levels (Record, Field-Non Value Based, Field-Value Based ):
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 PAY (pay rate change) or TER (termination).
Assume that you change the effective date of a termination action (TER) from November 15 to November 20.
When the effective date associated with this action changes, the system should:
Delete the old trigger associated with the changed source row.
Insert a new trigger with a new trigger effective date.
User Action |
Field Change |
Effdt/Effseq |
Trigger Action |
Trigger Effdt |
Source Field Value |
Trigger Event ID |
Existing Row |
PAY |
10/20/05 |
Insert |
10/20/05 |
PAY |
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 PAY (pay rate change) or TER (termination).
Assume that you change the Action value of a July 1, 2005 effective dated row from DTA (data change) to PAY (pay rate change), and that there is a second, preexisting row with a value of PAY and an effective date of January 1, 2006. This example shows that the latter row is affected by the change to the earlier row:
User Action |
Field Change |
Effdt/Effseq |
Trigger Action |
Trigger Effdt |
Source Field Value |
Trigger Event ID |
Existing Row |
DTA |
01/01/05 |
None |
PAY |
Event 1 |
|
Existing Row |
DTA |
07/01/05 |
None |
TER |
Event 1 |
|
Existing Row |
PAY |
01/01/06 |
Insert |
01/01/06 |
TER |
Event 1 |
Correction |
PAY |
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 DTA to PAY. Because trigger generation is based on field value changes, and there is no change between the July 1, 2005 and January 1, 2006 rows (both have a field value of PAY), the system deletes the trigger originally created for the latter row, and inserts a new trigger with a July 1, 2005 effective date. Note that there are no triggers for the DTA rows, as DTA is not a value that has been defined for trigger generation.
Special Rules for Field-Based Segmentation Triggers for Records Containing EFFSEQ (Effective Sequence) Field
There are special rules for managing field-based segmentation triggers if the record contains the field EFFSEQ (for example, the JOB record):
When the trigger definition is Field – Non Value Based, the trigger generation PeopleCode inserts a trigger for a given effective date using only the highest effective sequence row. That is, only the highest effective sequence row per effective date matters when the trigger definition is Field – Non Value based. This prevents unnecessary trigger generation when you enter first one effective sequence row and then another with the same effective date to correct errors in the first row.
When the trigger definition is Field – Value Based, the trigger generation PeopleCode inserts a separate trigger for each effective sequence row with a given effective date. In other words, all effective sequence rows are processed when the trigger definition is value based. This is to accommodate situations in which it is necessary or desirable to have multiple effective sequence rows. For example, there are some fields such as JOB.ACTION in which you might enter a transfer and a promotion one after another on the same day. This field would most likely have a value-based trigger definition.
In Global Payroll you can define segmentation triggers only for effective dated records, with one exception: you can define segmentation triggers for the begin and end dated earning and deduction assignment record GP_PYE_OVRD. This exception enables you to assign an earning or deduction to a payee on the Element Assignment by Payee (GP_ED_PYE) or Payee Assignment by Element (GP_ED_ELEM) components, and segment (and prorate) the element when the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the period end date.
For example, assume that an earning element E1 for 300 USD is assigned to a payee with begin and end dates of 10 and 20 June respectively (assume a monthly pay period), and that the system is set up to trigger segmentation from the earning and deduction assignment record for this element. Based on the assignment begin and end dates, the system will slice the pay period into three segments and process–and prorate–the element in the second slice:
Element |
Slice 1 June 1–10 |
Slice 2 June 11–20 |
Slice 3 June 21–30 |
Earning = E1 Calculation Rule = Amount Amount = 300 |
Element not resolved in slice 1. |
Resolved amount = 100 (proration factor = .333333333) |
Element not resolved in slice 3. |
Note. The only type of segmentation that can be defined for the GP_PYE_OVRD record is element segmentation.
See Also
In addition to setting up the system to generate triggers automatically, you can enter triggers manually on the Review Triggers component (GP_TRIGGER) by selecting the trigger type, the trigger effective date, the process definition, and other data needed by the system to initiate retroactive or segmentation processing.
See Managing Automatically Generated Triggers and Defining Triggers Manually.
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
Defining Segmentation Events and Types
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 generate triggers 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 to system to generate a trigger in response to changes to a specific field or group of fields in the record.
If you select Field, you must list the fields that you want to make sensitive to data changes in the List Fields With Trigger group box. You can further restrict the data changes that generate triggers by selecting the Dependent on Field Value Action check box for a specific field, clicking the List Field Values link, and specifying the values that trigger retro processing.
In addition, you must specify a trigger event ID or primary event ID at one of the following levels:
If you select Record as the trigger level, specify the trigger event ID in theTrigger Event ID field at the record level on the Trigger Definitions page.
If you select Field as the trigger level, and trigger generation is not dependent on specific field values, specify the trigger event ID at the field level in the List Fields With Trigger group box on the Trigger Definitions page.
If you select Field as the trigger level, and segmentation is dependent on specific field values, click the List Field Values link and specify the trigger event ID at the field value level in the Field Values group box on the Trigger Definitions – Field Values page.
In addition, if you select Field as the trigger level, you must enter a primary event ID at the record level in the Primary Event ID field on the Trigger Definitions page. This ID functions as the default event ID when the changed, added, or deleted row that triggers retro processing is the first row in the buffer (that is, a prior row cannot be found).
Note. The Primary Event ID field appears only when the trigger type is Retro and the trigger level is Field.
Setting Up Segmentation Triggers for Effective Dated Records
In Global Payroll, you can set up segmentation triggers for effective dated records and for a single begin and end-dated record—the earning and deduction assignment record GP_PYE_OVRD. In this section we discuss the steps for setting up segmentation triggers for effective dated records.
To set up segmentation triggers for effective dated records:
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 generate triggers by selecting the Dependent on Field Value Action check box for a specific field, clicking the List Field Values link, and specifying the values that trigger segmentation.
In addition, you must define a trigger event ID at the appropriate level:
If you select Record as the trigger level, define the trigger event ID at the record level on the Trigger Definitions page.
If you select Field as the trigger level, and segmentation is not dependent on specific field values, specify the trigger event ID at the field level in the List Fields With Trigger group box on the Trigger Definitions page.
And if you select Field as the trigger level, and segmentation is dependent on specific field values, click the List Field Values link and specify the trigger event ID at the field value level in the Field Values group box on the Trigger Definitions – Field Values page.
Note. The trigger event IDs tells the system what type of segmentation to use (period or element segmentation), and in the case of element segmentation, what elements (earnings, deductions, and other elements) to segment in response to a change in data. You define trigger event IDs on the Segmentation Event Definition page.
See Defining Segmentation Events and Types.
Setting Up Segmentation Triggers for The Begin and End-Dated Earning and Deduction Assignment Record (GP_PYE_OVRD)
You can set up segmentation triggers for the earning and deduction assignment record (GP_PYE_OVRD) if you want an assigned element to be sliced and prorated based on the assignment begin and end dates.
Note. If you want a segmented element to be prorated, you must associate the element with a proration rule on the earning and deduction definition pages.
To define a segmentation trigger for the earning and deduction assignment record:
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, enter GP_PYE_OVRD in the Record (Table) Name field, and select a trigger type of Segmentation.
Click the Add button.
The Trigger Definitions page appears.
When you define a segmentation trigger for the earning and deduction assignment record (GP_PYE_OVRD), the system automatically populates the fields on the Trigger Definitions page with these values:
Field |
Value |
Explanation |
Trigger Level |
Field |
Segmentation triggers generated from the GP_PYE_OVRD record are field level triggers. The field is automatically defined as PIN_NUM (Element Name). This means that segmentation triggers are generated only when earnings or deductions are assigned to payees and entered in the PIN_NUM (Element Name) field on the Payee Assignment by Element or Element Assignment by Payee components. |
Trigger Effective Date Type |
Begin-End Date |
The GP_PYE_OVRD record is a begin and end dated record. |
Field Name |
PIN_NUM |
This is the only field on the GP_PYE_OVRD record that is defined to trigger segmentation. |
Dependent on Field Value |
Selected |
When you define Segmentation triggers for the GP_PYE_OVRD record, the system requires that you positively identify the specific earning or deduction elements that trigger segmentation. These elements are the field values that must be entered in the Element Name (PIN_NUM) field on the Payee Assignment by Element or Element Assignment by Payee components. |
Click the List Field Values link to bring up the Trigger Definitions - Field Values page.
Use the Entry Type and Element fields on the Trigger Definitions – Field Values page to list the earnings and deductions that should trigger element segmentation when the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the period end date.
In addition, specify one of the following trigger options for each element:
Segment This Element
If you select this option, the system slices only the specified element.
Specify Trigger Event ID
If you select this option, you must specify a trigger event ID. The system then slices the selected element and any other elements included in the element list identified by the trigger event ID.
Note. The trigger event ID tells the system what elements (earnings, deductions, and other elements) to segment in response to a change in data. You define trigger event IDs on the Segmentation Event Definition page.
See Defining Segmentation Events and Types.
Warning! You must select the Active Anytime Within the Segment Period option on the Countries component (GP_COUNTRY) to fully implement segmentation triggers with the earning and deduction assignment record (GP_PYE_OVRD). If you do not select this option, the system issues the following warning when you add a segmentation trigger to a record: Warning -- 'Active Anytime within the Segment Period' on the Countries component has not been selected. (17000,4637) In order to take advantage of the functionality when the Earning/Deduction Assignment record (GP_PYE_OVRD) is indicated, you must select 'Active Anytime within the Segment Period' in the Process Payee Assignments group box on the Countries component.
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 Status |
To activate the trigger definition, select Active. |
Trigger Type |
Displays the trigger type that you selected to access this page. Options are: Iterative, Retro, and Segmentation. |
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 generate triggers by selecting the Dependent on Field Value Action check box for a specific field, clicking the List Field Values link, and specifying the values that should result in trigger generation. Note. When you define segmentation triggers for the GP_PYE_OVRD record, the system automatically sets the Trigger Level to Field. |
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. |
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 Effective Date 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 Effective Date 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. Note. When you define segmentation triggers for the GP_PYE_OVRD record, the system automatically sets the Trigger Effective Date Type to Begin-End Date. |
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. Note. When you define segmentation triggers for the GP_PYE_OVRD record, the system automatically sets the Field Name to PIN_NUM. |
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. When you define Segmentation triggers for the GP_PYE_OVRD record, the system automatically selects the Dependent on Field Value option. |
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 in relation to the date of a field value 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. |
Entry Type |
This field is available only when the trigger type is Segmentation and the record for which you are defining the trigger is GP_PYE_OVRD. Select Earnings to define an earning to trigger segmentation when it is assigned to a payee on the Element Assignment by Payee or Payee Assignment by Element components and the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the pay period end date. Select Deduction to define a deduction to trigger segmentation when it is assigned to a payee on the Element Assignment by Payee or Payee Assignment by Element components and the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the pay period end date. |
Element |
This field is available only when the trigger type is Segmentation and the record for which you are defining the trigger is GP_PYE_OVRD. Specify the earning or deduction (depending on the entry type specified above) that should trigger segmentation when it is assigned to the payee. |
Trigger Option |
This field is available only when the trigger type is Segmentation and the record for which you are defining the trigger is GP_PYE_OVRD. Valid values are:
|
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
The PeopleSoft system considers the effective date of a termination entered in the Action field in the JOB record to be the first day that a payee is no longer working (in other words, the day before the termination is the last day the payee is considered active). If you attach a trigger to this field to process retroactive terminations, the system, by default, sets the trigger effective date equal to the date of the termination row in JOB. This can create problems when the termination effective date is equal to the pay period begin date (meaning, the last day worked is the last day of the prior pay period). For example, assume that you enter a termination in JOB on February 1 after processing and closing the January calendar. In this situation, the system generates a trigger with an effective date of February 1, which is within the current period—a period in which the payee is "inactive" and will not be picked up for processing. Because there is no trigger in the prior, closed period (January), this period will not be recalculated and any rules you have set up to generate termination payments will not be processed. To avoid this problem, set the offset days for the Termination action value in the JOB record equal to -1.
See Also
Defining Retroactive Processing
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 is invoked. These parameters are:
&P_EMPLID
Identifies the EMPLID for which a trigger should be generated. Use field EMPLID for &P_EMPLID.
&P_FIXED_DT
Holds the value of the trigger effective date for records with a Trigger Effective Date Type of Fixed Date. It is ignored for records with a Trigger Effective Date Type of Effdt or Begin-End Date. Use &L_DT for &P_FIXED_DT.
The variable &L_DT needs to be assigned a value only in the case of Fixed Date type triggers. Examples are the positive input records, the Manual Positive Input table (GP_PI_MNL_DATA), and the Manual Positive Input Supporting Element Override table (GP_PI_MNL_SOVR).
Note. You can enter PeopleCode that invokes this function only if certain conditions are met, as discussed in example 2 below.
The following examples are taken from PeopleCode delivered with the database. They illustrate how to configure the PeopleCode for additional records in the system.
Example 1: Trigger Record = GP_PYE_SOVR
Sample PeopleCode:
PeopleCode on GP_PYE_SOVR.EMPLID.SavePostChange Declare Function Generate_Triggers PeopleCode FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula; Local date &L_DT; /*-----Function to generate Triggers for Global Payroll---*/ Generate_Triggers(EMPLID, &L_DT);
In this example, &L_DT isn't assigned a value, because the Trigger Effective Date Type for the Payee Supporting Element Override table (GP_PYE_SOVR) is not Fixed Date.
Example 2: Trigger Record = GP_PI_MNL_DATA (Manual Positive Input)
This record has a Trigger Effective Date Type of Fixed Date.
Sample PeopleCode:
PeopleCode on GP_PI_MNL_DATA.LASTUPDDTTM.SavePostChange Declare Function Generate_Triggers PeopleCode FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula; Local date &L_DT; Local Rowset &L_RS0; Component datetime &C_CAL_IDNT_TS; /*-----Function to generate Triggers for Global Payroll---*/ &L_RS0 = GetLevel0(); &L_DT = &L_RS0(1).GP_PI_MNL_D.PRD_END_DT.Value; If All(&C_CAL_IDNT_TS) Then Generate_Triggers(EMPLID, &L_DT); End-If;
In this example, &L_DT must be set to a value to be used as the trigger effective date for triggers generated from positive input.
With positive input, triggers must be generated with the period end date for the calendar that has the positive input. So, &L_DT is set as follows:
&L_RS0 = GetLevel0(); &L_DT = &L_RS0(1).GP_PI_MNL_D.PRD_END_DT.Value;
Note. GP_PI_MNL_D.PRD_END_DT has been assigned the value of PRD_END_DT for the calendar through earlier PeopleCode on GP_PI_MNL_DATA.ENTRY_TYPE_ID.RowInit.
The function can now be invoked. In the case of positive input, the trigger-generation mechanism needs to be invoked only if the calendar that has positive input has been identified:
If All(&C_CAL_IDNT_TS) Then Generate_Triggers(EMPLID, &L_DT); End-If;
Note. PeopleSoft recommends that when you define a retroactive or segmentation trigger, you also define an iterative trigger. If a calendar group has been calculated and data changes are subsequently made, unless an iterative trigger is defined, any retroactive or segmentation triggers generated from the data changes aren't processed until the next Identify phase.
See Also
Reviewing PeopleSoft Delivered Triggers
This section discusses how to:
View, add, or cancel segmentation triggers.
View, add, or cancel retroactive triggers.
View or change the trigger status for iterative triggers.
View iterative triggers by calendar group ID.
Use the Review Triggers (GP_TRIGGER) and Review Iterative Triggers (GP_TRGRITER_CALRUN) components to:
Review and manage triggers generated automatically by the online system.
Define retro and segmentation triggers manually when you want to bypass the setup for online trigger generation.
View the source record or field for a trigger as well as the field value changes that cause iterative, segmentation, or retroactive processing. This information is useful for debugging and troubleshooting when you are trying to determine why a particular instance of iterative, retro, or segmentation processing took place.
Note. The system does not display source data for manually defined triggers.
Note. You cannot define iterative triggers manually using the Review Triggers (GP_TRIGGER) or Review Iterative Triggers (GP_TRGRITER_CALRUN) components.
Warning! The pages in the Review Triggers and Review Iterative Triggers components enable you to cancel triggers. Do not cancel triggers while a payroll run is processing. This can lead to errors in your payroll results.
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 Record (employee record) |
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
Select the Source tab.
Use the Source tab to view the source record and field for a segmentation trigger.
The system displays either the source record, or both the source record and field for a trigger, depending on the trigger level:
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 segmentation triggers generated from the earning and deduction assignment record (GP_PYE_OVRD), the field name is PIN_NUM. 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. |
Values
Select the Values tab.
Use the Values tab to determine what field value change caused the system to generate a segmentation trigger.
The system displays field values only for triggers at the following trigger levels:
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
|
Country |
Same as the Country field on the Event ID and Source tabs. |
Effective Date |
Same as the 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. |
Date Value |
Displays the date value that generates a trigger. |
Numeric Value |
Displays the numeric value that generates a trigger. |
Element Name |
Displays the name of the element (earning or deduction) that causes a trigger to be generated (for segmentation triggers generated from the earning and deduction assignment record [GP_PYE_OVRD]). |
Adding Manual Segmentation Triggers
To manually insert a segmentation trigger:
Enter a country and an effective date on the Segmentation page – Event ID tab. The system uses the effective date entered here as the basis for the trigger effective date.
Specify an event ID for the trigger on the Segmentation page – Event ID tab.
The system uses the event ID to determine what type of segmentation to use and which elements to segment in the case of element segmentation.
The system sets the trigger source to Manual, and the trigger status to Active.
Note. Unlike automatically generated triggers, manual triggers are independent of any database change defined by a record or record and field combination on the Triggers Definition page. It is important to understand the potential consequences of creating manual triggers. Because they aren't linked to a specific data change, you might segment periods and elements where nothing has changed.
Updating and Canceling Segmentation Triggers
For automatically and manually generated rows of trigger data:
You can change the event ID.
You can change the trigger status from Active to Canceled.
You cannot reinstate a canceled trigger; you must add a new manual trigger.
For the effective date on generated rows of trigger data:
The effective date on the Segmentation page is the date in relation to which segmentation occurs.
You can change the effective date of a manually generated trigger.
You cannot alter the effective date of a trigger that was generated by the system based on predefined setup rules.
See Also
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. In Process: This value is assigned automatically by the system. You cannot update the trigger status when it is set to In Process. In addition, you cannot manually set the Trigger Status to In Process. The system issues an error if you attempt to do so. |
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. |
Values
Select the Values tab.
Use the Values tab to determine what field value change caused the system to generate a retro trigger.
The system displays field values (character, date, or numeric values) only for triggers at the following trigger levels:
Field, Non-Value Based.
Field, Value-Based.
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 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, Global Payroll delivers the following records with trigger PeopleCode attached. These are delivered as a starting point. You can add trigger-generating PeopleCode to other records to meet your specific business needs, or delete the PeopleCode from any of these records:
Note. Global Payroll trigger-generation logic is stored in the FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula PeopleCode. In order for a record to generate triggers, the GENERATE_TRIGGERS function stored there must be declared and called from the record in SavePostChange PeopleCode.
ADDRESSES
BEN_PROG_PARTIC
COMPENSATION
CONTRACT_DATA
DEP_BEN_ADDR
DEP_BEN_EFF
DEP_BEN_NAME
GP_ABS_EVNT
GP_ABS_OVRD
GP_OFFCYCL_A_VW
GP_OFFCYCL_M_VW
GP_OFFCYCL_M_VW
GP_OFFCYCL_U_VW
GP_PI_MNL_DATA
GP_PI_MNL_D_VW
GP_PI_MNL_E_VW
GP_PI_MNL_SOVR
GP_PI_MNL_SSN
GP_PYE_OVRD
GP_PYE_OVR_SOVR
GP_PYE_SECT_DTL
GP_PYE_SOVR
GP_RTO_TRGR
GP_RTO_TRGR_VW
HEALTH_BENEFIT
JOB
JOB_JR
LIFE_ADD_BEN
LIFE_ADD_BENEFC
PERSON
PERS_DATA_EFFDT
PER_ORG_ASGN
PRIMARY_JOBS
SCH_ASSIGN
SCH_MNG
SCH_TBL
WKF_CNT_TYPE
Note. PeopleSoft recommends that you set up period segmentation triggers for changes in the Pay System Flag and Pay Group fields on the JOB record.