Understanding Retroactive Processing

This chapter discusses:

• Standard retro setup in Global Payroll for France.

• Gross salary changes.

• Variations on standard retro processing.

• Loans and garnishments.

• Reporting and retroactivity.

• Delivered retro triggers.

• Collective changes to contribution calculation elements.

Note. This section assumes that you are familiar with the basic concepts of retroactivity discussed in PeopleSoft Enterprise Global Payroll PeopleBook. It does not summarize or explain retroactive processes described elsewhere in the documentation.

See Also

Defining Retroactive Processing

Standard Retro Setup In Global Payroll for France

In Global Payroll for France, retroactive changes in the current year are processed using the corrective method, and retroactive changes in previous years are processed using the forwarding method.

Note. The default retroactive method for France is corrective; however, the standard retro method is defined as varying based on the calendar year, with forwarding defined as the retroactive method for calculations that go back to previous years.

This setup addresses the most common cases of retroactivity, and enables you to:

• Calculate retroactive changes to the gross salary.

• Apply the current contribution rates to the gross salary deltas.

• Declare contributions calculated retroactively.

• Manage most retroactive changes:

  • URSSAF scheme changes.

  • Contribution eligibility changes

  • Participation in unemployment (ASSEDIC) or retirement funds (AGIRC/ARRCO).

  • Change of establishment or company.

  • Retroactive hiring or departure.

  • Block recalculation of loans and garnishments.

  • Block recalculation of social contributions for completed years.

Note. Global Payroll for France does not deliver specific forwarding rules. If you decide to apply the delivered logic for processing retroactive changes—corrective for the current year and forwarding for past years—you must define your own forwarding rules.

Gross Salary Changes

This section discusses:

• Managing gross salary changes in the current year.

• Gross salary calculation steps and elements.

• Controlling retro calculations.

Managing Gross Salary Changes in the Current Year

The logic used to manage gross salary changes depends on the organization collecting the contributions:

• For URSSAF, ASSEDIC, and CSG/CRDS, the system performs a partial recalculation of the gross salary elements.

• For other contributions such as ARRCO and tax levies, Global Payroll for France performs a full recalculation of the gross salary elements.

This section provides an overview of both of these approaches.

Note. The explanations provided here deal specifically with recalculations in the current year using the corrective rules delivered by PeopleSoft. PeopleSoft does not deliver specific rules for processing retroactive changes in prior years.

Partial Recalculation

Some organizations such as URSSAF and ASSEDIC require that gross salary elements be submitted to the contribution rates in effect on the payment date. For example, if a payee receives a retroactive pay increase, the contribution rates of the current period should be applied to the gross salary deltas, rather than those in effect in the recalculated period (as the pay increase is only realized in the current period).

Global Payroll for France manages gross salary changes for URSSAF, ASSEDIC, and CSG/CRDS by:

• Recalculating the gross salary, taking into account the elements modified retroactively.

• Storing the recalculated gross in accumulators.

• Retrieving the old value of the gross rather than the recalculated gross to determine contributions in a prior period.

  Note. The system recalculates the gross, taking into account the retroactive changes in salary. However, when calculating the funding base for URSSAF and ASSEDIC, the system does not use the recalculated gross but the "old value" of this gross.

• Recalculating funding bases, based on the old gross value, using standard rules.

• Using the annual regularization of contributions principle to process the recalculated gross deltas in the current period. Based on this principle, the system compares, in the current period, the gross salary effectively used (submitted gross) to calculate the funding bases, and the recalculated gross salary (real gross).

  • If no retro calculation is triggered or if the gross salary hasn't changed retroactively, the submitted gross and the real gross are equal, and there are no gross deltas to process.

  • If a retro calculation occurs with a change in the gross salary, the submitted gross and the real gross are different. This difference (positive or negative) corresponds to the gross delta and is added to the gross calculated for the current period, where it is submitted to current contribution rates.

Note. The process described here is referred to as a partial recalculation because the gross salary used is the "old" or "previously calculated" gross.

Note. If a contribution rate changes retroactively but there is no change to the gross salary (no gross salary delta), the new rate is applied to the old value of the funding base. This is in keeping with the rule that the contribution rate to apply is the one in effect on the payment date.

Full Recalculation

For other contributions such as ARRCO, AGIRC, contingency funds, and tax levies, Global Payroll for France performs a full recalculation of the gross salary. In other words, the system does not retrieve the old gross values, but fully recalculates both the gross salary and the funding bases, and replaces the original calculations with the new ones (in keeping with the logic of the corrective retro method).

In addition, Global Payroll for France uses the full recalculation method whenever a retro mismatch situation occurs, regardless of the social organization. The reason for this is that mismatches produce reversal segments that completely cancel the initial calculations. This prevents the old value of the gross salary elements from being retrieved during retroactive processing.

Note. As a general rule, the full recalculation method is used to process gross salary changes for social organizations with rates that are fixed for the year. The partial recalculation method is used to process changes for social organizations with rates that occasionally vary during the year.

Warning! If the system fully recalculates the gross salary and funding bases in a situation in which rates also change between the recalculated and the current period, the gross retro deltas may be submitted to the old rate instead of the current rate. If this occurs, it is possible to manually enter, for a specific earning, the gross delta using positive input in the current period. However, you should consider the possible consequences of this solution, as it may prevent salary history from being correctly recorded in the system.

See Understanding Complex Retro Processing.

Gross Salary Calculation Steps and Elements

This section discusses:

• Gross salary and funding base calculation steps for URSSAF, ASSEDIC, and and CSG/CRDS.

• Example of a gross salary recalculation for URSSAF.

Gross Salary and Funding Base Calculation Steps for URSSAF, ASSEDIC, and CSG/CRDS

Global Payroll for France goes through the following steps to calculate the gross salary and funding bases for each organization:

1. Initialization: The system determines the ceilings to use for the different organizations (URSSAF, ASSEDIC, and CSG/CRDS).

2. Gross salary calculation: The system calculates the different earnings and deductions included in the gross salary.

3. URSSAF, ASSEDIC, and CSG/CRDS-specific gross base calculation:

   • If there is a retroactive calculation, the system retrieves the old value of the base.

   • If the calculation is in the current period, the system calculates the gross deltas not submitted to contributions, and adds them to the current gross salary to determine the gross base.

4. Calculation of contribution funding bases: The system calculates the funding bases for the contributions by applying the ceiling limitations and exemptions based on the gross base for each organization (URSSAF, ASSEDIC, and so on).

The following tables list the elements used to calculated the gross salary and funding bases:

The calculation process uses these elements as follows:

1. When a segment is processed in retro corrective mode, Global Payroll uses the formulas URS FM BRUT REEL, ASS FM BRUT REEL and TAX FM BRT CSG REEL to:

   1. Retrieve the old value of the gross segment accumulator (URS AC BRUT SG, ASS AC BRUT SG, ARC AC BRUT SG, AGI AC BRUT SG, PRV AC BRUT SG, TAX AC ASS CSG SG).

   2. Assign the old value to the gross segment accumulator processed in the retro calculation.

   3. Add the recalculated gross value to the yearly real gross accumulator (URS AC BRUT REEL AN, ASS AC BRT REEL AN, TAX AC BRT CSG AN).

2. When a segment is processed in the current period or processed in retro forwarding mode, Global Payroll uses the formulas URS FM BRUT REEL, ASS FM BRUT REEL, and TAX FM BRT CSG REEL to:

   1. Calculate the gross delta not submitted to contributions by subtracting the submittedgross accumulator (URS AC BRUT AN, ASS AC BRUT AN, TAX AC ASS CSG AN) from the realgross accumulator (URS AC BRUT REEL AN, ASS AC BRT REEL AN, TAX AC BRT CSG AN).

   2. Add the delta calculated in step 2a to the current gross segment accumulator (URS AC BRUT SG, ASS AC BRUT SG, ARC AC BRUT SG, AGI AC BRUT SG, PRV AC BRUT SG, TAX AC ASS CSG SG).

   3. Submit the amount calculated in step 2b to the funding base and contribution calculations for each social organization, using the contribution rates in effect in the current period.

Note. The URSSAF, ASSEDIC, and CSG/CRDS calculations described here are referred to as partial recalculations because the gross salary used is the "old" or "previously calculated" gross. By contrast, when calculating other contributions such as ARRCO and tax levies in corrective mode, the system fully recalculates the gross salary to determine the funding bases.

Example of a Gross Salary Recalculation for URSSAF

The following example of an URSSAF calculation illustrates the processing logic.

In this example:

• An employee is paid 100 EUR in January.

• In February, the employee's salary increases to 110 EUR. This change is retroactive to January.

In the January recalculation (V2R1), the system uses the old value of the gross segment accumulator (URS AC BRUT SG) calculated in V1R1 (100) rather than the true, recalculated gross (110) stored in the annual real gross accumulator (URS AC BRT REEL AN). In the January recalculation period, the value of the annual submitted gross (URS AC BRUT AN) is therefore less than the value of the real gross (URS AC BRT REEL AN).

In February, the difference between the submitted and the real gross is eliminated, as the delta between these amounts—calculated by subtracting the submitted gross accumulator (URS AC BRUT AN) from the real gross accumulator (110 – 100)—is added to the current February segment gross (110), and the resulting amount is added to the total annual amount submitted to contributions (URS AC BRUT AN).

Controlling Retro Calculations

You can override the delivered partial recalculation of changes to the gross salaries for URRSAF, ASSEDIC, and CSG/CRDS by assigning a value of 1 to the following variables:

When you change the value of these variables to 1, the system fully recalculates and replaces the gross salaries in the recalculation period. If you do not override the variables URS VR RTO CONTROL, ASS VR RTO CONTROL, or TAX VR RTO CONTROL, the system uses the logic described earlier to manage the URSSAF, ASSEDIC, and CSG/CRDS gross accumulators.

Note. The only override value you can enter for the retro control variables is a value of 1. Other overrides are not considered. In other words, you are only authorized to force a full recalculation of the gross salary in cases of retroactivity.

Note. You can override the value of these variables at several different levels depending on your requirements: the pay entity level, the pay group level, or the payee level.

Variations on Standard Retro Processing

The standard solution for managing gross salary changes in the current year is:

• Partial recalculation of gross salary elements used to process contributions for URSSAF, ASSEDIC, and CSG/CRDS.

• Full recalculation of salary elements used to process contributions for ARRCO and tax levies.

• Full recalculation of salary elements in any situation in which there is a segment mismatch.

However, because different kinds of retroactive change require different solutions, PeopleSoft delivers several variations on the standard approach.

This section discusses variations that apply to:

• Gross salary changes with a change of establishment or company.

• Ceiling changes.

• Funding base exemption changes.

• Changes in the lump-sum funding base for apprentices.

• Contribution calculations for finalized years.

• Net guarantee.

• Contribution eligibility.

• Hiring and departure.

• Isolated amounts.

• Inactive segments.

Gross Salary Changes with a Change of Establishment or Company

Normally, when a payee moves from one establishment to another, the accumulators storing the gross salary deltas are submitted to contributions in the new establishment. The "old" establishment pays the gross salary deltas, while the current establishment processes the contributions on these deltas.

However, when there is a change in company, the accumulators storing the gross deltas are not included in the current period calculation for the new company. This is because company is used as the key for the accumulators that store the gross deltas, and these deltas are associated with the old company. To force the gross regularization to occur within the new company's contribution calculations, PeopleSoft forwards a "dummy" element from the recalculated period to a "dummy" element in the current period. If an employee changes company, an inactive segment is processed for the employee for the old company (assuming that company is defined as a Payment Key at the pay entity level).

At a technical level, PeopleSoft manages this type of change by:

• Verifying that the retro calculation system element is equal to Corrective.

  If this condition is met, the "dummy" earning RETRO FICTIF is calculated and returns a value of 1.

  Note. If you override the delivered Corrective retro method during implementation, the solution described here is not applied.

• Mapping the element RETRO FICTIF to a second "dummy" earning element, RTRO INACTIF. This second earning receives the value of 1 contained in RETRO FICTIF when there is corrective retro (according to the retro process override definition entered on the Retro Process Overrides page).

• Forwarding the earning RTRO INACTIF (with a value of 1) to the current period.

  When this happens, there is no segment in the current period having the same payment keys as the recalculated segment. Because of this, an inactive segment is triggered in the current period for the "old" keys.

  Note. If multiple segments are recalculated (for example, in December you recalculate all periods going back to September), the earning RTRO INACTIF will receive the value of 1 for each segment retroactively calculated as corrective (1 for September, 1 for October, 1 for November).

For this solution to work, when you define payee selection on the Calendar component (GP_CALENDAR ) prior to processing a payroll, you must include active payees plus payees with pending retroactive changes. Based on this selection, inactive payees are considered in the calendar calculation as long as they have retro forwarded adjustments coming from the dummy element for the inactive segment.

Warning! Global Payroll for France supports the retro-corrective solution described here only if you define company as a payment key at the pay entity level. This restriction is based on legal requirements for calculating, for URSSAF and ASSEDIC, contributions limited to a ceiling on a yearly basis and for a unique company. PeopleSoft does not support the use of payment keys such as contract number and establishment.

Ceiling Changes

Changes to the ceiling values for URSSAF and ASSEDIC can affect funding base calculations even when there is no change to the gross salary. Global Payroll for France manages ceiling changes in corrective mode by using the old value of the gross to calculate the segment funding base, while applying the new ceiling values. Because of the ceiling changes, the final value of the funding base may be different from the initial value.

Funding Base Exemption Changes

Exemption changes can affect funding base calculations even when there is no change to the gross salary. Global Payroll for France manages these changes in corrective mode by using the old value of the gross to calculate the segment funding base, while applying the new exemptions. Because of the exemption changes, the final value of the funding base may be different from the initial value.

Note. Retroactive changes to funding base exemption percentages can result in the recalculated funding base being different from the initial funding base. This can lead to a situation in which there are multiple rates to declare for the same contribution in the same DUCS declaration. In such cases, the new DUCS norm enables you to declare the old rates for URSSAF and ASSEDIC.

See Generating DUCS.

Changes in the Lump Sum Funding Base for Apprentices

The gross salary is not used to determine the funding base for apprenticeship contracts. Instead, the system calculates a lump-sum funding base adjusted to the age of the apprentice and the duration of the contract. There is no annual regularization of contributions for the apprenticeship contribution as the lump-sum base is always under the ceiling. If the conditions used to calculate the lump sum funding base change retroactively, the recalculated lump-sum funding base is used, and this base is submitted to the rate in effect during the recalculated period.

Note. Gross salary changes do not impact funding base calculations for apprentices, because this calculation is independent of the salary.

Contribution Calculations for Finalized Years

Because it is not possible to change contributions after a calendar year has been declared in the DADS report, the URSSAF TRC, and the ASSEDIC BDA, Global Payroll for France does not manage the impacts of retroactive changes to gross salary elements in previous years. Customers must manage these by direct contact with the social organizations. In general, regularization changes for finalized years are declared manually.

Note. Global Payroll for France uses the forwarding method to manage retroactive calculations in past years. You can override this setup and use the corrective method to manage all employees or specific cases. However, doing so could result in contributions for previous years being including in the current DUCS declaration, which is forbidden by the social organizations.

Net Guarantee

To manage the net guarantee calculation when there is corrective retro processing, Global Payroll for France:

• Blocks the recalculation of the net guarantee amount during recalculation.

  The net guarantee amount is defined as Do Not Recalculate during retro calculations. This means that even if the IJSS amount changes retroactively, the net guarantee amount remains identical to the initial calculation.

• Includes any IJSS deltas in the current period and then performs the net guarantee calculation.

See Also

Understanding Net Guarantee Processing

Contribution Eligibility

An employee who is eligible for a specific set of contributions may be declared retroactively eligible for another set of contributions or ineligible for contributions. Conversely, an employee who is ineligible for contributions can be retroactively declared eligible for these contributions. Global Payroll for France has developed rules to manage such retroactive eligibility changes. These are described in the following sections.

Eligibility changes for URSSAF Contributions

This table describes how Global Payroll for France manages eligibility changes related to URSSAF contributions:

Eligibility Changes for ASSEDIC Contributions

This table describes how Global Payroll for France manages eligibility changes related to ASSEDIC contributions:

Eligibility Changes for Retirement and Contingency Contributions

This table describes how Global Payroll for France manages eligibility changes related to retirement and contingency fund contributions:

Eligibility Changes for Levies

This table describes how Global Payroll for France manages eligibility changes related to levies:

See Managing Gross Salary Changes in the Current Year.

Hiring and Departure

Global Payroll for France has developed solutions to manage retroactive hiring and departures, their impact on URRSAF, ASSEDIC, and other social contributions. The following table describes how the PeopleSoft system manages these changes:

Isolated Amounts

Isolated amounts are amounts paid at or after termination that are submitted to specific AGIRC retirement contributions.

Global Payroll for France delivers specific rules for managing isolated amounts processed retroactively. These rules are triggered when:

• There is a retroactive termination.

• There is a retroactive payment of an amount after a termination.

• There is a retroactive termination or payment following a termination for an employee who has changed categories between the different recalculated segments.

Three elements have been created–using the retro process override setup–to retrieve any deltas created by the retroactive calculations:

• RETRO SI: This earning element retrieves the gross salary deltas of the accumulator GEN AC BRUT SG.

• RETRO SI AGI: This earning element retrieves the gross deltas of the accumulator AGI AC BRUT SG (AGIRC gross base segment accumulator).

• RETRO DELT SI: This earning element retrieves the deltas of the accumulator AGI AC SI MNT SG (isolated amounts segment accumulator).

Note. These elements are used in the formula RTO FM RECUP SI only when the segment processed is INACTIVE and the current calculation is not retroactive.

When processing isolated amounts at or after termination, the system:

1. Calculates the difference between RETRO SI and RETRO DLT SI.

2. Adds the results of this calculation to any isolated amounts in the current period.

   The system stores the difference between RETRO SI and RETRO DLT SI in the variable RTO VR SI, and adds the value of this variable to the current isolated amounts accumulator AGI AC SI MNT SG.

Note. This calculation treats the gross salary deltas as isolated amounts, but processes only deltas that have not already been considered as isolated amounts and submitted to contributions.

When an employee changes category during the year (for example, from employee to manager), there is a possibility that this calculation will treat all gross deltas as isolated amounts, when only the gross deltas for periods when the payee was a manager should be considered. To avoid this, the system calculates the difference between RETRO SI and RETRO SI AGI. If there is a difference between these elements, the system knows that the employee changed category in the recalculated period. It stores this difference in the variable RTO VR SI AGI, and uses it to limit the isolated amounts delta (so that deltas for the periods when the employee was not eligible for AGIRC contributions are not included in the isolated amounts).

Inactive Segments

To process retroactivity in certain situations, Global Payroll for France triggers inactive segments in the current period. For example, this occurs in situations in which an employee changes company between the different segments recalculated.

Inactive segments have the following characteristics:

• No ceilings are calculated in inactive segments.

  Because the employee is not considered "present" in inactive segments, there is no ceiling calculation. The progressive regularization of contributions occurs normally for the segment with a gross increase, but there is no change in the annual ceiling amount.

• The different elements (variables, accumulators) storing the worked/paid days or hours are set to 0 in the inactive segment.

• The inactive segment is not considered in the calculation of seniority days (stored in the accumulator GEN AC JOUR ANC).

• No SMIC control occurs in inactive segments, as no paid hours can be calculated for these segments.

• The fiscal and social reinstatement calculation is triggered for inactive segments.

• Inactive segments are declared in the DADS-U. The begin and end dates of these segments are set to 1 January (01/01) as required by the norm.

Loans and Garnishments

By law, loans and garnishments cannot be recalculated during retroactive processing.

Global Payroll defines loan elements with the Retro Recalculation option set to Do Not Recalculate. However, because loans are triggered by positive input, and positive input overrides the Retro Recalculation option, you should be careful not to enter new loan data in a closed period.

By contrast, Global Payroll defines garnishment elements with the Retro Recalculation option set to Always Recalculate. This can lead to situations in which garnishments are reprocessed in a prior period. For example, if there is retroactivity and a retro mismatch occurs, the system tries to recalculate all elements, including garnishments. To prevent this from happening, Global Payroll for France uses the array RTO AR RESULT PAIE to retrieve the original value of the garnishments in the payroll result tables whenever there is retroactive processing.

Note. The earnings/deductions for which the array RTO AR RESULT PAIE retrieves previously calculated values are those with a Category of RTO (Retro Element Retrieved in Array). If you want to use this array to prevent the recalculation of an earning/deduction that you have defined yourself, you should assign the earning/deduction to the same category.

See Retroactivity Calculations.

Reporting and Retroactivity

This section discusses:

• Declaration methods.

• Managing retroactive changes to rates in the DUCS declaration.

• Viewing and modifying the declaration method used for reporting.

Declaration Methods

The retroactive process impacts not only the calculation of social contributions for URSSAF, ASSEDIC, and AGIRC/ARRCO, but also the declaration of these contributions. PeopleSoft follows the DUCS norm for declaring contributions. The latest version of these norms supports corrective declarations, and PeopleSoft has taken advantage of the new standards to develop solutions for reporting retroactive changes.

There are two kinds of declarations for reporting retroactive changes to social contributions:

• Additive declarations.

  In an additive declaration, the funding bases from recalculated periods are added to the funding base in the current period.

  Note. Funding bases can be added together only when there is no difference in contribution rates between the recalculated periods and the current period, as the DUCS norm allows only one rate to be declared per period.

• Rectified declarations.

  In a rectified declaration, separate "rectification" reports are issued for each period recalculated. In other words, bases are not combined and different rates can be attached to the base deltas as well as the current period base.

  Note. Rectified declarations can be generated regardless of whether the rates used in the current and recalculated periods are the same or different.

The official bodies for URSSAF, ASSEDIC, and AGIRC/ARRCO have defined the following declaration method for each category of social contributions:

• URSSAF.

  For the URSSAF declaration, the DUCS program differentiates contributions calculated in different periods. For example, if there is a retroactive base salary change in December going back to the beginning of the year in January, the DUCS declaration will consist of 11 rectified declarations (from January to November) and one normal declaration (for December).

  If there is a difference in the rates between the current and prior periods, each retroactive change in a funding base must be declared separately and identified by the period regularized, just as is the case when only the funding base changes.

• ASSEDIC and AGIRC/ARRCO.

  For ASSEDIC and AGIRC/ARRCO, the DUCS program combines contributions calculated in different periods as long as the rates are the same in the prior and current periods (the recalculated funding bases are added to the current period funding base).

  If there is a difference in rates between current and prior periods when contributions are recalculated, the DUCS report will display the same contribution multiple times with the different rates and corresponding bases.

  Note. Conflicting rates are retrieved only if for a specific DUCS type, the setup indicates that additive declarations are done.

Managing Retroactive Changes to Rates in the DUCS Declaration

When a company reprocesses prior periods to correct contribution rates that are above or below the official rates, the resulting calculations are recorded in the DUCS declaration as follows:

• The initial calculations done using incorrect rates are reversed in the current declaration.

  Note. From the perspective of the social organization, it will appear that these reversals use an invalid rate.

• The recalculations done with the correct rates are declared for the full funding base.

When the social organization receives the "corrected" declaration, it may issue a rectification to force either immediate payment of missing contributions (if the original rate used was below the official rate), or a reduction in future payments (if the original rate used was above the official rate). This is because the "corrected" DUCS declaration displays invalid rates for the contributions that have been reversed.

To avoid this, Global Payroll for France provides an exception page (DUCS Override Rates FRA page) on which you can override the rates used in the actual payroll calculations with the rates you want to include in the current DUCS declaration. For example, if you use an incorrect rate to calculate the Work Accident contribution, you can use this page to replace the incorrect rate with a rate acceptable to the social organization.

Note. Overriding rates can create discrepancies between the contributions calculated in the system and the contributions declared in the DUCS report. These discrepancies can affect financial accounting, as the amounts recorded in the payroll system will differ from the amounts actually paid. You can track and manage these discrepancies using the DUCS Rate Override Audit report (GPFRDUCO). This report records the difference between the calculated and the declared amounts resulting from a rate override.

See Overriding DUCS Rates.

Viewing and Modifying the Declaration Method Used for Reporting

You can view the declaration method defined by the official bodies for each organization on the DUCS Types page. If the rules for making retroactive declarations change, you can use this page to modify the method.

Note. The delivered declaration methods reflect the positions of the respective social organizations during the development of Global Payroll for France. You should consult the latest DUCS norms to verify that these declaration methods are still current. In particular, you may need to change the ASSEDIC setup to RECTIFICATIVE if the ASSEDIC chooses this declaration method.

See Reviewing Declaration Codes for DUCS Types.

Delivered Retro Triggers

The different standard situations for which Global Payroll for France delivers retro triggers are:

• Changes to compensation data.

• Changes to the JOB record.

  The trigger for job date changes is defined for the following fields: Action, Company, Establishment, Pay Group, Contract Number, Job Code, FTE, Paid FTE, Collective Agreement, and Employee Status.

  Note. Most of the changes in the JOB record trigger retro, segmentation, and iterative processing.

• Changes to contract data.

  This trigger is defined at the field level for the following fields: Contract Type, Contract Begin Date, Contract End Date, and Contract Number.

• Change to contract data specifically for France.

  This trigger is defined for the following fields: Multiple Employer Rate, Gross Reduction Percentage, Category Status, and Social Security Code.

• Changes to absence events.

  This trigger is defined at the record level.

• Changes to positive input.

  This trigger is defined at the record level.

• Changes to Element Assignment by Payee and Payee Assignment by Element data.

  This trigger is defined at the record level.

• Changes to supporting element overrides.

  This trigger is defined at the record level.

• Changes to the employee schedules.

  This trigger is defined at the record level.

Note. These triggers are provided as models of trigger definitions. You may need to modify these triggers and define additional triggers to manage situations that are unique to your organization.

See Also

Setting Up Triggers

Collective Changes to Contribution Calculation Elements

Collective changes to contribution calculation elements can be processed using mass triggers. The setup of these triggers is documented in PeopleSoft Enterprise Global Payroll PeopleBook.

See Also

Setting Up Mass Triggers