Setting Up Country Data

This chapter provides an overview of PeopleSoft Enterprise Global Payroll core functionality in Spain and discusses how to:

• Set up statutory rates.

• View delivered elements.

Understanding PeopleSoft Enterprise Global Payroll Core Functionality in Spain

This section discusses:

• Retroactivity.

• Payment keys.

• Accumulators.

• Segmentation.

• Triggers.

• Rounding rules.

• Process lists.

Retroactivity

Retroactivity is the process of going back in time and recalculating prior calendars because changes were made after the original calculation was run. When retroactive processing occurs for a payee, the system recalculates each element generated for the payee. The difference between these results is the retro delta.

In Global Payroll, two methods are available for calculating retro:

• Corrective

• Forwarding

The most common retro method used in Spain is the corrective method. Using this method, you go back and recalculate the elements of the pay run, updating all accumulators, including balance accumulators and calendar period accumulators. The recalculated pay run replaces the previously calculated run. However, the original pay run calculation remains available for auditing and reporting purposes. Rather than forwarding retro deltas to the current calendar as an adjustment, the system sends any adjustment to Net to be Paid for the recalculation period to manage the banking process.

Note. You can also set up retro with the forwarding method during your implementation if it fits your company's needs.

PeopleSoft Enterprise Global Payroll for Spain and Retroactivity

PeopleSoft Enterprise Global Payroll for Spain delivers the corrective method because this is the standard (statutory) way to manage retroactivity in Spain.

• The retro process (RETRO) uses the corrective method without variance.

• Retro overrides are used in PeopleSoft Enterprise Global Payroll for Spain. They serve the following purposes:

  • To facilitate reporting retro calculations to Hacienda.

    The system forwards the tax information for the current period using the IRPF RTR element. This element receives the value from the IRPF AFW element that is forwarded into IRPF RTR in a retro calculation of a month in the same year. In this way, the current month has all of the information affecting taxes. Also, the current tax percentage can be applied to the delta coming from a retro calculation.

  • To manage retro across different tax years.

    For these cases of retro, the system forwards tax values to the current month but it forwards them to elements other than IRPF FWD because they need to be taxed in a different way. In addition, these tax values are reported separately during yearly reporting. Later, the monthly and year-end reports retrieve those values and print them accordingly.

    PeopleSoft Global Payroll also enables you to manage retro from previous years as if they were from the same fiscal year. To accomplish this, modify the value of the variable CLI VR RT A PR FLG (previous year retro flag) with a value that is not Y.

    Note. Define retro overrides on the Retro Process Overrides page.

• You can define your own retro event.

  See Defining Retroactive Processing.

• You can define your own retro triggers according to your company needs.

• You can define your own pay entities according to your company needs, but the common setup in PeopleSoft Enterprise Global Payroll for Spain is:

  • Calendar period: Starts in January.

  • Fiscal period: Starts in January.

  • Backward limits: Depends on how you set up PeopleSoft Enterprise Global Payroll for Spain.

  • Forward limits: Two years.

Launching Retroactivity Across Different Tax Years

When the prior period is in a different tax year, your company can't collect the tax due and pay it to Hacienda because the prior year is already closed for tax reporting. This applies to both situations of underpayment and overpayment.

The solution is that, when you are reporting to Hacienda, deltas of the previous year are considered. The deltas are considered in Model 111 of the current month and in Model 190 for the current year (at the end of the year) as income from a previous tax year. The system calculates the IRPF tax for those deltas by applying a fixed percentage (currently at 15 percent), instead of the valid IRPF percentage in the retro period or the current period.

Note. Taxes and social security are calculated differently. Social security calculation is not affected when the retro calculation is across different tax years. The way to calculate retro in this case is the same as the one used in calculating retro in the current year.

Example of Calculating Retroactivity for a Different Tax Year

Assume that both the calendar period and the fiscal period for your pay entity start on January 1. If the retro starts in a different tax year, the fiscal period determines how the retro of taxes is calculated. The following list and table provide the details for this example:

• Launch the calculation for the May 2006 pay period.

• Launch a retro calculation for November 2005.

• Report the tax calculation for the deltas from all the launched retros from November until April in the Model 111 of May 2006.

  In the case of the retro for November 2005 and December 2005, the IRPF for the delta is calculated with a 15 percent tax rate. Model 190 will reflect it accordingly.

Note. This table summarizes all the information that you need for your retro calculation. This table is only a suggestion using the common setup parameters that are delivered with PeopleSoft Enterprise Global Payroll for Spain. You may find that your company's requirements are different and may need to define retro differently during your implementation.

Running Corrections in PeopleSoft Enterprise Global Payroll for Spain

The pure retro process calculates from a target calendar, which receives forwarded tax data regarding deltas and updates the balance accumulators of the recalculated month. You then report the delta from the retro processing for the target calendar through complementary reporting . Thus, if you have already reported social security contributions for a given month and need to recalculate, you use pure retro processing. For example, if a company signs a labor agreement in May but needs to increase salary starting from January 1, then the company must run pure retro processing from January in the May payroll (target calendar). The company then reports the deltas from the retro calculation in a complementary report within the May FAN file.

Corrections, on the other hand, are cases in which you need to rerun a finalized payroll but have not yet reported to social security for that month. Corrections enable you to report the delta on the regular monthly reporting rather than through complementary reporting. You are thus correcting a finalized payroll.

With PeopleSoft Enterprise Global Payroll for Spain, you can run corrections by using a specific run type or by using Global Payroll core off-cycle functionality. The "Managing Off-Cycle Payments" chapter explains both methods in detail.

See Also

Managing Social Security Calculation

Calculating Taxes

Defining Retroactive Processing

Managing Off-Cycle Payments

Payment Keys

In PeopleSoft Enterprise Global Payroll for Spain, you can define payment keys. Options are Company, Contract Number, Department, and Establishment ID. When the payment keys of the current period don't match the payment keys in the retro period, the deltas are managed as a separate gross-to-net calculation in the current calendar period. When a retro is launched that affects more than one calendar period, the deltas that come from each one will be summed only when the payment keys match.

For example, company information is needed for tax reporting purposes. The Agencia Tributaria needs to know which company the employee is working and being paid from.

So when retro is launched, you may need to report the tax calculation of the deltas related to the prior company. Or you may need to report the tax calculation of the deltas related to the current company. Which calculation you report depends on which company is declaring the payment to the fiscal territory.

Because PeopleSoft Enterprise Global Payroll for Spain uses the corrective retro, it does not forward deltas into the current period in most cases. However, regarding tax calculation, the income deltas are transferred to the current period. You should review this during implementation and set up according to your organizational requirements.

See Also

Defining the Organizational Structure

Defining Retroactive Processing

Accumulators

In PeopleSoft Enterprise Global Payroll for Spain, two types of accumulators exist:

• User-defined accumulators (balance accumulators):

  Accumulate different elements for any period of time for which you want to accumulate any number of elements.

• Auto-generated accumulators (payment accumulators):

  Accumulate a particular element during a defined period.

For user-defined accumulators, four functional areas exist that have specific prefixes:

• Absences accumulators (AUS).

• Earnings and deductions (AJB, FNQ, and GEN).

• Social security (SS).

• Taxes (TAX, RETJ).

For auto-generated accumulators, two functional areas exist that have specific suffixes:

• Absences (ADJU, BAL, ENT, TAKE).

• Deductions (ATR).

In PeopleSoft Enterprise Global Payroll for Spain, you define accumulators for several earnings and deductions. Accumulators for earnings include those for base salary, seniority pay, mejora voluntaria, complemento absorbible, and extra period payments. Accumulators for deductions include social security deductions.

Customer-Oriented Segment Accumulators

PeopleSoft Enterprise Global Payroll for Spain also delivers a set of customer-oriented segment accumulators. When you define an earning or deduction element, you can assign the element to these accumulators. You need to decide which accumulators you need to update, based on the following questions:

• How does the element affect gross?

• Is the element taxable?

• Does the element contribute to social security?

Depending on your answer to these questions, you need to select the appropriate accumulator. The following tables provide details about the customer-oriented segment accumulators:

Compensation:

Taxes:

Note. You can include an earning in just one of these tax accumulators.

Social Security:

Segmentation:

Other purposes:

See Also

Element Ownership and Maintenance

Setting Up Accumulators

Segmentation

In Global Payroll, you can segment elements based on different events or changes. Two types of segmentation exist:

• Period segmentation:

  The system calculates each element more than once and keeps the results of these calculations separate.

• Element segmentation (also known as slice segmentation):

  The system segments only the element selected. Only one gross-to-net result set exists.

PeopleSoft Enterprise Global Payroll for Spain uses element segmentation in most cases. A slice can occur for many reasons:

• Changes in rate codes.

  This can occur due to manual changes or automatic changes due to a salary plan, category, or multiple components change.

• Changes in an employee's annual salary (target compensation)

• Changes to risk code.

• Change in tax location (fiscal territory).

• Changes in the social security work center code (SSN).

  This normally happens when an employee changes establishments.

PeopleSoft Enterprise Global Payroll for Spain uses period segmentation for these changes:

• Changes in company (when an employee transfers to a different company).

• Changes in pay group.

• Changes in employees' payroll system.

  PeopleSoft Enterprise Global Payroll for Spain uses the Payroll System field to determine employees' payroll system.

Note. PeopleSoft Enterprise Global Payroll for Spain delivers segmentation setup and triggers as sample data. You must decide which changes should trigger segmentation for your company. View the delivered segmentation rules and triggers using pages in Global Payroll in your demo installation.

Retroactivity Segmentation Mismatching

When the system recalulates a segmented period for retro and the segmentation dates of the original calculation don't coincide with those of the recalculation, this is called a segment mismatch, and it affects how the system calculates retro deltas.

When segment dates match and payment keys are the same, the system recalculates the original segments to determine the new values for each segment. It then subtracts the old value from the new value for each pay element to determine the retro deltas. It writes the new results to the output tables.

When segment dates don't match, the system treats the old and new values as if they belong to separate segments. It creates reversal segments for each segment that existed in the prior calculation and creates new recalculated segments. A reversal segment has no results because it does not go through gross-to-net processing. The only results that they system writes to the output result tables are for deltas and balance accumulators. For calculating deltas, the system uses zero for the new values.

The new recalculated segments go through gross-to-net processing and generate new values. While processing recalculated segments, the system cannot use "Previous Value" functionality to get deltas as it normally does during retro processing because the previously calculated values for every element are resolved to zero. In this case, the system retrieves the previous value through arrays.

When reading previously calculated values, the system sums the results for all slices and segments previously calculated for the calendar group and stores those values in container elements (RTR AC xxxxx). Then when the system subtracts the previous values from the recalculated values to determine retro deltas, it uses the proportional part of the total previous value, prorated with respect to the current segment days. The proration rule being used is:Active days in the current slice ÷ Active days in the period

Active days in the period is normally defined as the days between the period begin date and period end date, but in the event that an employee changes pay groups in the month, the system uses the period until the effective date of the pay group change. For cases in which contributions are linked to vacations, the system applies the total previous value to the segment in which there is now a termination.

Active days in the period normally means days between Period begin date, and Period End date, but in case employee changes of pay group in the month, then we will consider the period till the effective date of the paygroup change. In case of contributions linked to Vacations we are applying the total previous value to the segment in which there is now the termination

Note. For banking purposes, PeopleSoft Global Payroll manages reversal segments by inserting rows in GP_PAYMENT for the reversal segments as negative amounts. Then, the new calculation inserts the new values. This means that you must select the "Combine Payment" functionality whenever you process reversals.

Whenever you need to generate retro deltas or read previously calculated values, you need to analyze whether you want to use container elements (RTR AC xxxxx). To use container elements you must:

1. Create the container element (RTR AC xxxxx).

2. Update the formula RTR FM MAPPING to map the source element—the element for which you want to retrieve previous values—to the target container element.

3. Update the formulas that makes use of "Previous Value" functionality to use the container element in the case of segmentation mismatching.

4. Update the accumulators that determine the behavior of the container elements in the case of element segmentation: RTR AC SEG TAX and RTR AC SEG SS.

   RTR AC SEG TAX (Tax Elements slicing) includes all container elements that should be sliced when the system processes segmentation trigger events that affect taxes.

   RTR AC SEG SS (SS Elements to slice) includes all container elements that should be sliced when the system processes segmentation trigger events that affect social security.

Forwarding Retro Deltas to Inactive Segments

PeopleSoft Global Payroll creates inactive segments to process retro deltas that are forwarded when the pay entity of the source month does not match the pay entity of the current month. This usually occurs whenever payment keys don't match. PeopleSoft Global Payroll also creates inactive segments when there are pending retro changes for inactive employees. The system requires a target calendar to which it can forward deltas (late terminations process through retro).

The system skips gross-to-net calculation during inactive segment processing. You need to ensure, however, that you manage the retro deltas that get forwarded using the setup variable CLI VR CAL DD SG I (Calc IRPF DD in Inac. Segment). This variable indicates to the system whether you want to process tax deductions during inactive segment calculation. Valid values are:

• A anular: Select if you do not want the system to calculate retro tax deductions with negative net values.

• C calcular: Select if you want the system to calculate retro tax deductions with negative net values.

See Also

Defining Segmentation

Triggers

In Global Payroll, triggers are used to detect online changes to data that should result in some type of system action. Examples of common data changes that might use triggers are the hiring of a new payee, a change in pay rate, or a change in job location.

Three types of triggers exist: iterative, segmentation, and retro triggers.

PeopleSoft Enterprise Global Payroll for Spain delivers triggers as sample data. Review the delivered triggers and adjust existing triggers, or define your own triggers based on your company's needs.

Iterative Triggers

This table lists some iterative triggers that are delivered with PeopleSoft Enterprise Global Payroll for Spain as sample data:

Segmentation Triggers

This table lists some segmentation triggers that are delivered with PeopleSoft Enterprise Global Payroll for Spain as sample data:

Retroactivity Triggers

This table lists some retroactivity triggers that PeopleSoft Enterprise Global Payroll for Spain delivers as sample data:

Segmentation Triggers with Earning and Deduction Assignments

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 to segment (and prorate) the element when the assignment begin date comes after the pay period begin date, the assignment end date comes before the period end date, or both.

PeopleSoft Enterprise Global Payroll for Spain has set up the following earnings so that the system automatically segments and prorates them (using the proration factor defined on the earning definition pages) when the assignment period covers only a portion of the pay period:

If you want to set up additional earnings and deductions to trigger segmentation and proration when they are assigned to payees and the assignment period covers only a portion of the pay period, access the Trigger Definitions component (GP_TRGR_SETUP) and add these elements to the segmentation trigger definition for the GP_PYE_OVRD record.

In the case of deductions or nonbasic earnings, you also need to specify formula GEN FM SEGMNTCN as a post-process formula and specify the proration to use. PeopleSoft Enterprise Global Payroll for Spain delivers GEN PO DIAS SLICE that you can use or modify, or you can create a new formula to fit your requirements.

See Also

Setting Up Triggers

Rounding Rules

When you resolve an element that is a numerical value, you often need to round the resulting value. You'll use rounding rules to do this.

After you define a rounding rule element, apply it to other elements. The rounding rule can be applied to any component of an earning or deduction, to the resolved amount of an earning or deduction, or within a formula.

The following table describes the delivered rounding rules that PeopleSoft Enterprise Global Payroll for Spain provides as guidelines:

See Also

Calculating Taxes

Managing Social Security Calculation

Defining Calculation Elements

Process Lists

PeopleSoft Enterprise Global Payroll for Spain delivers the following process lists:

Calculate IRPF percentage either as part of the normal payroll (in the GEN PR CALC NOM process list) or as a separate calculation (in the TAX PR CALC IRPF process list).

Setting Up Statutory Rates

To set up statutory rates, use the Statutory Rates ESP component (GPES_STATUTORY).

This section provides an overview of statutory rates and discusses how to set up statutory rates.

See Also

Setting Up Statutory Severance Days

Understanding Statutory Rates

PeopleSoft Enterprise Global Payroll for Spain delivers statutory rates for:

• Minimum employee salaries.

• Interest charged on employee loans.

• Percentage of travel expenses and the dietas earning that are exempt from tax and social security.

These rates are defined by the government. PeopleSoft Enterprise Global Payroll for Spain delivers and maintains these rates as system data.

Page Used to Set Up Statutory Rates

Setting Up Statutory Rates

Access the Statutory Rates page (Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Addl Rates, Ceilings, Values, Statutory Rates ESP, Statutory Rates).

Daily Minimum Salary	Enter the minimum daily wage established by law.
Monthly Minimum Salary	Enter the minimum monthly wage established by law.
IPREM (Daily) (Indice Publico de Renta de Efectos Múltiples)	Enter a value to use to calculate the daily wage that is exempt from taxes and social security contributions.
IPREM (Monthly) (Indice Publico de Renta de Efectos Múltiples)	Enter a value to use to calculate the monthly wage that is exempt from taxes and social security contributions.
Part Time Minimum Salary	Enter the daily minimum salary for part-time employees.
Statutory Interest	Enter the interest rate established by law. You can apply this interest rate or another rate to any employee loan. If you apply a lower rate, the difference is considered salary in kind.
Excess Pct. over IPREM (excess percentage over Indice Publico de Renta de Efectos Múltiples)	Enter the percent to use to calculate the exempted amount for the public transportation complement and for salary in-kind earnings.

See Also

Public Transportation and Distance Complement

Viewing Delivered Elements

PeopleSoft Enterprise Global Payroll for Spain provides some setup elements that you can customize to fit your business requirements. The following table lists these setup elements:

Note. You can find more information about these setup elements in the context of their related business processes throughout the chapters of this PeopleBook.

The PeopleSoft system delivers a query that you can run to view the names of all delivered elements designed for Spain. Instructions for running the query are provided in the PeopleSoft Enterprise Global Payroll 9.1 PeopleBook.

See Also

Understanding How to View Delivered Elements