Managing Used or Obsolete Triggers
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.