Skip to Content
Public Sector

Defining PEP benefits and impacts on results

This document focusses on maintenance and calculation of benefits. It will guide through the pre-requisites to assigning benefits to a PEP Projection. It also gives a detailed view on how the benefit amount is calculated in the PEP Results. Using this document, one can have a clear picture on how the benefit assignment affects the PEP Results.

1. Maintaining Benefit Rules

The accumulator details and the months/pay periods for each Benefit Plan under a particular Benefit Area are maintained using the Benefit Rules Screen. If these rules are not maintained, then there won’t be any Benefit Records generated in the PEP Calculation even if the benefit is assigned to the positions and employees being processed. The highest level is a Benefit Area. Benefit Plan(s) are then assigned to Benefit Areas. For details on creating Benefit Areas and Plans please refer to the following link to maintain Benefit Rules:

Maintaining Benefit Rules - SAP Public Budget Formulation - SAP Library

Once the Benefit Area and Benefit Plans have defined, we start here with describing the details of the Benefit Plan.

In the New Benefit Plan popup, shown below, a set of fields can be seen. Each of these fields has the following significance:

  • Benefit Plan: This field signifies the Benefit Plan which will be associated with the Benefit Area selected. It basically specifies the Benefit Plans under a particular Benefit Area.
  • Wage Type: Wage Type Indicates the type of Calculation (E – Earnings, ST – Statutory Benefits. This field is not relevant for calculation.
  • Calculation Basis:  Calculation Basis The accumulator that will be used to calculate percentage based benefits. The calculation basis can be the base salary or any accumulator.
  • Calculation Order: If the calculation basis for any of the benefit is an accumulator, then the benefits contributing to the accumulator should be calculated first. This order can be prioritized using the calculation order.
  • Benefit Start Period: The month that the benefit needs to start or be reset to track accumulation earnings. This is used in benefits that have yearly maximums.
    For example, Social Security (OASDI) is based on an annual earnings cap for 2007 of $97,500.
    The Cap is reset in January.
  • Commitment Item: This is the default commitment item for the benefit.

The final step for maintaining benefit rules is maintaining the benefit months or pay periods and accumulators. In Fiscal PEP projections, the months for which the benefit amounts are to be calculated need to be maintained. Use the Months tab to maintain the benefit months. These months remain the same for each year i.e. the benefit is calculated for the same months every year.


In PBF 8.1 Release, we have included the feature – Pay Period benefit calculation. If benefits are to be calculated for a Pay Period Projection then the pay periods for the benefit has to be maintained using the Benefit Rules Screen. Use the Pay Periods table to maintain the benefit months. Also, the pay periods are maintained w.r.t. Pay year i.e. for each pay year, the benefits can be configured for a different set of pay periods.

On both the Months and Pay Periods tabs is an Accumulators section. If the benefit amounts that are calculated during PEP projections should be included in accumulators then the accumulator(s) can be assigned here.

2. Maintaining Benefit Rates

This feature allows the user to maintain the benefit rates. It is this amount/percentage which is used to calculate the amount which has to be given as benefit to the employee or position. If these rates are not maintained, then there won’t be any Benefit Records generated in the PEP Calculation even if the benefit is assigned to the positions and employees being processed.

Please refer to the following link to maintain Benefit Rates:

Maintaining Benefit Rates - SAP Public Budget Formulation - SAP Library

In the New Benefit Rate Screen, a set of fields can be seen. Each of these fields has the following significance:

  • Benefit Range Step: This is like a key value which is used in case we need to maintain different benefit rates for different time periods.
  • Start Date: The date from which the benefit rate details mentioned will be valid.
  • End date: The date till which the benefit rate details mentions will be valid.
  • Longevity Months: Number of months before a longevity pay is triggered, starting from the employee longevity date.
  • Min Amount: This value comes into picture in case of accumulator benefits. The calculated benefit amount should not be less than the amount    maintained in this field.
  • Max Amount: This value comes into picture in case of accumulator benefits. The calculated benefit amount should not be more than the amount maintained in this field. Once the total amount exceeds the max amount maintained, the benefits are discontinued i.e. they are not calculated further.
  • Amount: The annual benefit amount is maintained here i.e. total amount given as a benefit to an employee/position. This value is fixed.
    E.g. suppose the amount mentioned here is 12000, and the year has 12 periods, then the periodic benefit would be 12000/12 = 1000.
  • Rate: It determines the rate percentage. It is rate percent of the calculation base amount which is calculated as the periodic benefit.
    E.g. suppose the periodic salary is 10000 and the rate maintained is 10%. The calculation basis is ‘BASE’
    then the benefit amount will be: 10% of 10000 = 1000.
    The benefit rate maintenance screen allows you maintain the benefit rate details for the required benefit plan for different time ranges i.e. you can maintain different rates for different times.
    E.g. From 01.01.2000 to 31.12.2020   = 4 percent (one set of values)
             From 01.01.2021 to 31.12.9999        = 6 percent (other set of values)

3. Benefits in general Projection Scenarios

3.1. Benefit Assignment

Benefits can be assigned at three levels:

  • Job Level, using the Job Maintenance Screen.

    To know about maintaining Job MD, please see the link below:
    Job Maintenance - SAP Public Budget Formulation - SAP Library

    We can maintain benefits at the ‘Job’ level. These benefits are inherited by the corresponding position, during a PEP Projection, if they are not maintained at the Position MD
    .
  • Position Level, using the Position Maintenance Screen.

    To maintain Position MD, please see the link below:
    Position Maintenance - SAP Public Budget Formulation - SAP Library

    Note: We can assign benefits to position master data if we want to calculate benefits. In a general scenario, benefits are likely to be used. However, benefits can be considered as optional as they may or may not be required for PEP projection. If benefits are not maintained at Position MD, they are inherited from the Job MD.
  • Employee Level, using the Employee Maintenance Screen

    To maintain Employee MD, please see the link below:
    Employee Maintenance - SAP Public Budget Formulation - SAP Library

    Note: If benefits are not maintained at Employee MD, then they are inherited from the Position MD and if they are not maintained at Position MD, then they are inherited from the Job MD.

3.2. Benefit Record Generation

The Benefit Rules and Benefit Rates should be properly maintained for the benefits assigned in the respective MD. The benefit records are calculated along with the salary records as PEP Results. The Benefits Records are generated if the position/employee being processed for PEP Calculation has some benefits assigned for the projection duration.

Example:

If 1 employee and 1 position (vacant) is being qualified for PEP Calculations, such that each of them have a benefit assigned to them, then,

The number of salary records generated = 12 * 1 (employees) + 1 * 12 (position)    = 24

The number of benefit records generated = 12 * 1 (employees) + 1 * 12 (positions)  = 24

Therefore, the cube will have 48 generated records.

Note: The above projection is being run for 1 year with an assumption that the benefits are maintained for the entire year with proper benefit rates.

These Benefit records can be seen in the projection cube results with the benefit area and benefit plan fields populated with the applicable benefits. Records with blank benefit area and benefit plans represent salary. To have more granular information about the benefit accumulators, the respective position and employee DSO’s are to be checked. Please refer to the next section for more details.

3.3. Benefit Calculations

The benefit is calculated for each of the already calculated salary records – Fiscal Period Projection or Pay Period Projection. This implies that the monthly/pay period salary will act as the base salary amount for the calculations.

Benefit calculation depends on the Benefit Rules and Benefit Rates Maintained for the assigned Benefit.

Example:
Let Benefit Plan B1, under Benefit Area B, is configured for all the months i.e. Benefit B1 will be calculated for the entire year for each month.

Let the Benefit Rate maintained be as follows:
Fixed Amount = 12000

Variable Rate = 10%

The Variable Benefit amount calculation logic is same for both Fiscal Period Projection and Pay Period Projection.

  • For Fiscal Period Projection:

Let the Fiscal Period salary (FM Amount) calculated be 26000 for one employee.

Then the monthly benefit for Benefit Plan B1 will be:

= Variable Benefit Amount + Fixed Benefit Amount

= (10% of FM Amount) + (Fixed Benefit Amount / number of months configured)

= 10% * 26000 + 12000 / 12

= 2600 + 1000 = 3600

So, an amount of 3600 is calculated for the benefit for each period.

  • For Pay Period Projection:

If the pay period is not crossing the fiscal year/period i.e. no split takes place, then the variable and fixed amount is calculated using the same logic as the Fiscal Period Projection, the only difference being that the fixed benefit amount is divided by the number of pay periods for the respective pay year instead of the no. of months configured.

If the pay period crosses over a fiscal period/year, the following approach is used:

The variable benefit amount is calculated by multiplying the benefit rate percent by the FM amount calculated for the particular period.

Note: This FM Amount is already split with respect to the fiscal period/fiscal year for the respective pay period. Hence, no further splitting of the benefit amount is required.

In this example we will use 26 bi-weekly pay periods for year 2014.

Continuing the above example for Pay Period Projection, Benefit Calculation:

Pay Period Benefit Amount for B1 for bi-weekly pay period type, pay year 2014 will be:

= Variable Benefit Amount + Fixed Benefit Amount for each period

Suppose the pay period crosses two fiscal periods:

Period range: 26.01.2014 to 08.02.2014, clearly, 6 days of the period are in Fiscal Period 1 and the remaining 8 days in fiscal period 2. Total number of days in the period is 14. Therefore, the amount split will happen as follows:

          There will be 2 salary records in the results for this pay period split w.r.t. the fiscal period.

Let FM Amount for Fiscal Period 1, period 1 = 6000

Let FM Amount for Fiscal Period 2, period 1 = 8000

Therefore, variable amount will be:

For Fiscal Period 1, Pay Period 1: 10% * 6000 = 600

For Fiscal Period 2, Pay period 1: 10% * 8000 = 800

To Calculate Fixed Amount:

          Period fixed benefit amount = Fixed Benefit Amount / number of periods configured

Let, the benefit be configured for entire year, and the number of pay periods be 26

Therefore,

Fixed benefit amount for each period = 12000 / 26 = 461.54

Pay Period PEP gives results by pay period and fiscal period. So if the pay period crosses over two fiscal periods, then the period fixed amount is also split accordingly.

Amount for fiscal period = (number of period days in fiscal period / total number of period days) * Benefit Amount per period

For Fiscal Period 1, Pay Period 1: 6 / 14 * 461.54 = 197.80

For Fiscal Period 2, Pay Period 1: 8 / 14 * 461.54 = 263.74

Total benefit:

For Fiscal Period 1, Pay Period 1: 600 + 197.80 = 797.80

For Fiscal Period 2, Pay Period 1: 800 + 263.74 = 1063.74

Therefore, an amount of 797.80 will be given as benefit for pay period 1 fiscal period 1 and an amount of 1063.74 will be given as benefit for pay period 1 fiscal period 2.

4. Detailed information about Benefit calculation basis with PEP

Normally the PEP projection cubes are used as a basis for BW queries for reporting of PEP results. However sometimes the desired result data is not contained the PEP cubes. For those cases the underlying MonthWise DSOs may offer a solution.

During PEP executions the Monthwise DSOs are populated with more granular results, which are aggregated and then posted to the PEP cube. There are also some additional fields captured in those DSOs including Benefit Cost Basis. The thought here is that perhaps the YTD salary reporting might be more accurate by using the Benefit Cost Basis data in the Monthwise DSOs.  For cases where certain benefits are to be included as base salary, the benefit Accumulators can be used for this. Then the benefit cost basis will show the monthly cost basis for each benefit and can be summarized for an annual salary amount. It is only available in the Monthwise DSOs.  The DSO data is redundant but it stores more granular levels of information.

Monthwise DSOs

Here are the Monthwise DSOs – there is one for Position and one for Employee:

Note that to keep this data after a projection run a flag needs to be set appropriately in the Projection screen. The flag ‘Post results only to Cube’ should be unchecked (off). This setting will retain the data in the Monthwise DSOs after posting to the Cube. This flag will improve the processing time at the cost of consuming more memory as the results will be stored in the Monthwise DSOs and the Projection Cube. Having the ‘Post results only to Cube’ flag set on cause PEP turn run longer as the PEP engine has to delete the data from DSOs after posting the result to the Cube. So the DELETION time is extra.

The reason for setting the flag is to save the memory. The flag is found on the Projection Scenario screen and is turned off in this example:

Projection results

In this example we will have an employee getting 4 different benefits. The benefits have a specific order for calculating, 1-4. All are based on the GROSS accumulator.  In addition, we have GROSS1 accumulator as a ’dummy’ benefit, whose purpose is to show the cost basis for the salary + those benefits to be considered a part of salary.

The calculation order is important as those benefits that contribute to accumulators will increase those accumulators so that the subsequent benefits will see that cost basis increase.

HRAL PVFD and SPAN benefits are configured to contribute to the following accumulators:

HRAL represents a benefit that is based on one accumulator (BASE) but contributes to both GROSS and is considered part of salary (GROSS1 accumulator).

PVFD represents a benefit that is based on GROSS but does not contribute to GROSS, but is considered part of salary (GROSS1 accumulator.

SPAN is similar to HRAL, except it is not consider part of salary.

A portion of the results of the projection run are shown below. The data comes from the Employee Monthwise DSO and shows Employee 295 salary and benefits HRAL, PVFD and SPAN for fiscal periods 001 2012 and 002 2012:

Important points:

  • The first row with blank Benefit Area and Plan represents salary as taken from the pay scale table (132,000 annually / 12 = 11000 in Amount if FM currency). The Benefit Calc Basis Amount is blank is this field is only considered for benefit calculations.
  • Next listed are the HRAL and PVFD and SPAN benefits. For each benefit you will see a record with a blank accumulator and a record for each accumulator to which the benefit has been configured.  (Since HRAL had 2 accumulators it gets 3 records here).
    • The records with the blank Accumulator show the benefit cost basis Amount.
    • HRAL calculation basis is 11,000 as it is based on BASE accumulator.  Its cost of 1100 is added to the GROSS and GROSS1 accumulators.
    • Next the SPAN benefit is calculated, and it also contributes to the GROSS accumulator. It is calculated first (cost basis = 11,000 salary; cost = 2200) and then the cost is added to the GROSS accumulator. 
    • PVFD calculation basis is 14300 = 11000 salary + 1100 from HRAL + 2200 from SPAN. It’s cost of 2860 is added to the GROSS1 accumulator
  • TOTL has the cost basis of 14,960 = 11,000 salary + 1100 from HRAL + 2860 for PVFD. The amount of 149 for TOTL is necessary in order for the benefit to get calculated – we set it at 1%. If the amount was 0 then no record would be produced. This is obviously a work-around to get the TOTL salary cost basis; the amount associated with TOTL should be should ignore FM_AMT1 of TOTL record for other key figures.
  • Note that only the records with the blank accumulators will be written to the projection cube as per the aggregated levels in the cube. They can also be suppressed in a query when reporting from the DSO.
  • In this example, summarizing the TOTL benefit cost basis amounts for the year would give the annual salary amounts including the appropriate benefit. For reporting Total Salary, you could define a restricted key figure with condition Ben Plan = TOTL. Also you Step Increases

Step increases can be detected in either the Monthwise DSOs or the Projection cube results. When there has been a step increase, one of the Pay Scale attributes changes, typically the Pay Scale Level.  For this example, the employee’s pay level went from B to C at fiscal period 007 2012. Using the Monthwise DSO we can see the salary and benefit cost basis increases by comparing the associated amounts:

The above example is for Fiscal Period Projection. However, similar approach is used for Pay Period Projection as well. Also, the Monthwise DSO’s mentioned here correspond to the Fiscal Period Projection DSO’s. For Pay Period projection we provide a separate set of Periodwise DSO’s and Infocubes for both Employee and Positions. For more details, please refer to the “PEP Execution” document.

Former Member

No comments