Public Sector

# PEP FAQ

##### Tags: peppbf
• This document is a collection of frequently asked questions regarding PBF PEP (Personnel Expenditure Planning). If you have additional questions please use the discussion area to add new questions and we will update this document accordingly.

# PEP Configuration

Q2.1.1 What is the significance of Package Size maintained in SPRO Configuration for parallel processing?

Package Size defines the total number of Employees/Positions to be executed in each Work Process. It’s so crucial to set the package size to optimize the performance of PEP calculation.

It’s always advised to set the Package Size in such a way that the total number of resultant records generated out of each work process shouldn’t exceed 100000 (1 Lakh).

Example:

The formula to calculate the number of records that PEP will generate is:

Total no of Calculated records =

( number of employee + number of positions)

* average no of benefits per employee / position

* average no of allocation

* projection duration in fiscal period

Number of Employees is 10000, Positions are 10000, and projection duration of  2 years and average number of 9 benefits considered for this scenario.

Data volume in the /PBFBI/PROJ_1 is 1,300,550 and in the /PBFBI/PROJ_2 is  17,800,221

In this example, we are assuming that there are 9 benefits and no allocations and the duration is 2 years. Hence it should be 100000/(10*24) ~ 400. Any packet size less than 400 will give the optimal results but it is advised to maintain minimum packet size of 50.

Q2.1.2 What is the difference between Projection Start and End Period maintained in SPRO configuration and Projection Screen Parameters?

Projection Start and End Period maintained in SPRO configuration is the basis for Employee’s/Position’s STEP (Promotion or Grade Change) Calculation. This should be uniform across all projections. Otherwise the result will deviate from one Projection to another.

Projection Start and End Period maintained in Projection Screen is the basis for posting the results into the Projection Cube. These values are not relevant for PEP Calculation.

# Functionality differences in various PBF releases

Q3.1.1 What are the differences between Pay Period Fiscal Period PEP and Pay Period PEP?

Fiscal Period PEP is the original PEP that was delivered in PBF 7.1 and 8.0. Pay Period PEP was introduced in PBF 8.1. The following table outlines the differences between the two applications.

PEP Parameters / ScenarioFiscal Period PEPPay Period PEP
Configuration Pre-requisites

Maintain Process Chain Configuration

Configure Fiscal Year Variant

Maintain Process Chain Configuration

Configure Fiscal Year Variant

Configure Pay type(s)

Maintain Pay Period Process Chains Configuration

Results PostingsCalculates salaries and beneftis for employees and positions based on fiscal period. Results are based on a fiscal period which is equivilent to a calendar month.Calculates salaries and beneftis for employees and positions based on pay period. Results are based on pay periods and fiscal periods. The pay period duration is set based on the pay type (weekly, bi-weekly, monthly, semi-monthly, quarterly, etc.)
What-if ProjectionsSupportedNot Supported
Distribution RuleSupportedNot Supported
Flexible Source SelectionNot SupportedSupported
Attrition and Backfill ProjectionsNot SupportedSupported
Re-run FunctionalitySupportedNot Supported

Q3.1.2 What new PEP functionalities were provided in PBF 8.0?

The following table describes the new functionalities

New PEP features in PBF 8.0Functionality / Usability Description
Versioning of Master Data / Save Master Data OptionAllows to capture the master data used for the PEP calculation which in turn is used as the basis for What If Projections. The Employee and Position MD used must come from Employee and Position InfoObjects and is stored in DSOs for use in What If Projections
Continuity in Step CalculationsPEP Engine will maintain continuity in Step Calculation for the Employees and Positions with multiple tim slices and having the same attritube values for the salary related fields
Employee - Position Job InterdependencySupports Employee and its corresponding Position if they are assigned to different Jobs. In PBF 7.1 this was considered an error
Multiple CurrencySupports different currencies in Employee, Position and Pay Level MD. Master data records with different currencies will be processed with reference to FM Area Currency. An additional Key Figure of Alternate Currency will contain the additional currency, other than the FM Area currency.

Posting Results only to Projection Cube Option

Provides an option to post results only to the Cube. The PEP engine deletes teh results from the Month wise DSOs after the DTP run

What If ProjectionsAllows additional scenarios to be executed based on a previously run projection (reference projection) reusing the master data from the reference projection

# What If Projections

Q4.1 A What-if projection requires an underlying reference projection. How is a reference projection produced?

Execute a normal (fiscal) projection scenario with the ‘Save Master Data’ checkbox selected.

Q4.2 In the PEP What-if Scenarios, how are Pay Scale and Employee Benefit data entered in the selection screen used in PEP calculations?

Changes made in the Pay Scale Tab in the Step Date, Allocation and Benefit Supplemental Data will only be applied to those employees and positions that are assigned to the Pay Scale parameters specified (Country grouping, Pay Scale Type, Pay Scale Area, ES Grouping, Pay Scale Group, Pay Scale Level and validity period). Allowed changes are limited to only Step Months, Next Pay Scale Group and Next Pay Scale. Furthermore the Pay Scale and Employee and Position Master Data need to have the correct data. For example, the salary amounts, currency, etc. must also have been maintained via the Pay Level Maintenance screen, the Promotion Date must have been maintained for the employee via the Employee Maintenance screen, and so on.

Q4.3 In the PEP What-if scenarios, if I change the pay scale salary MD, will I see that change reflected in the what-if or do I have to re-create a new reference projection before I would see that change in a what-if? For example, I created a reference projection. Then I made a change to a salary increase in the pay scale level master data. If I create a what-if for the reference projection, will the salary increase from the MD be in effect for the what-if – or  – would I first have to create a new reference projection?

• Any changes made to Employee or Position Master Data will require a new reference projection to be created reflecting these changes before they will be reflected in a what-if projection. The Employee and Position Master Data used to calculate what-if projections results is based on the master data that was in effect at the time the reference projection was executed.

• Any changes made to Pay Level or Benefit rates will be reflected immediately in what-if projections. The Pay Level and Benefit rates used to calculate what-if projections results is based on the current rates maintained at the time the what-if projection is executed.

# Pay Period PEP

## General Questions

Q5.1.1 What is the minimum PBF release required to run Pay Period PEP?
You must be at least on PBF release 8.1 to run Pay Period PEP.

Q5.1.2 What are the different payroll schedules (pay types) that are supported by Pay Period PEP? How to maintain PayTypes?
Pay Period PEP supports the payroll types that SAP HCM supports. These include:

• Monthly
• Semi-monthly (exactly 24 periods per year)
• Monthly (exactly 12 periods per year)
• Weekly (typically 52 periods per year; can have up to 53)
• Bi-Weekly (typically 26 pay periods per year; can have up to 27)
• Every four weeks (typically 12 pay periods per year; can have up to 13)
• Annually (one pay period per year)
• Quarterly (4 pay periods per year)
• Half-yearly (2 pay periods per year)

These pay types can be loaded into the system by executing the BC Set /PBFBI/PAY_TYP. Additionally these can be copied into new pay types if the existing pay types are not adequate. Pay Period types are used to validate the Pay Period Table entries, to confirm that the correct numbers of pay periods are defined for each year.

Q5.1.3 How are pay periods maintained in the PEP Pay Table?
PEP Pay Table entries (/PBFBI/PAY_PRD) cannot be maintained manually. The data must be uploaded to the table from a file. The file should come from the legacy Payroll system. Program /PBFBI/PPRD_PAY_PERIOD_UPLOAD is provided to load the table entries from a comma delimited (.csv) file. The program is executed from the PBF IMG node ‘Upload Pay Period Table from file’ or transaction /PBFBI/PAY_PRD_UPLD. See program documentation for more details. The Pay Type designated in the file must be defined in the PEP Pay Period Type table /PBFBI/PAY_TYP in order for the upload program to load the data.
The PBF IMG node ‘Display Pay Period Table Entries can be used to display records in the Pay Period table.

Q5.1.4 Can more than one pay period type be uploaded / used by Pay Period PEP?
Yes. The file to upload pay periods can contain more than one pay type.  PEP Pay period projections can be run for any pay period type that contains valid data in Pay Period table.

Q5.1.5 What types of checks are done by the Pay Table Upload program?
The following file checks are performed:

• The input file exists and is not currently opened by any other process.
• File length is below 25000 bytes. This is a required security check.
• Data can be converted from Comma Delimited file to a column based file.
• Dates can be converted to an appropriate date format. NOTE: all SAP Netweaver date formats are accepted in the file. However, the user executing the program MUST set their user profile date format to match the date format in the file. This can be confirmed by comparing the data in the input file to the user profile setting (System -> User Profile -> Own Data. Set the date format to match the date format used in the file.

Once all of the file checks have passed, the actual data in the file is further validated as follows:

• Pay period type in the file exists in the PEP pay type table (/PBFBI/V_PAY_PRD). More than 1 pay period type data can be contained in the file (i.e. weekly pay periods and quarterly pay periods)
• Each pay year in the file must have the minimum or maximum pay periods as defined by the pay period type. The program will consider partial pay years an error. For example, if by-weekly pay period type is being loaded, each pay year must have at least 26 pay periods (minimum) defined and can have up to 27 pay periods (maximum) defined.
• There must not be any missing pay periods or gaps between pay periods
• Each records 'From' pay period date must be less than the 'To' pay period date
• The pay period to and from dates must be sequential without any gaps.. The 'From' date on a record must be the next day after the previous records 'To' date. This includes when the pay year rolls to the next year.

Q5.1.6 What happens to Pay Period table entries if the Pay Table Upload program is re-run?
The upload program will not delete any pay table entries. Once data in the upload file is validated it will overwrite any existing entries and append any new entries. A typical use-case is to add a new year of pay periods each year as PEP will need to project further into the future.

Q5.1.7 Can both Fiscal Period PEP and Pay Period PEP be executed?
It is expected that customer will either execute Fiscal Period PEP with optional What-if Projections OR Fiscal Period PEP with optional Attrition and Backfill Projections. Note that Pay Period PEP writes results by pay period and fiscal period, so the need to execute both types of projections is not considered a valid scenario and hence not supported.

Q5.1.8 If Fiscal Period PEP has been used in earlier versions of PBF and it is preferred to use Pay Period PEP as of PBF release 8.1 what needs to be done?

• Follow steps in the PBF 8.1 Upgrade Guide to install the additional BI content that is needed.
• Once content has been installed The Pay Period type(s) needs to be maintained and Pay Period table entries need to be uploaded to the system.
• All PEP master data, such as job, position, employee, pay scale and benefits, is used by both Fiscal Period PEP and Pay Period PEP.
• There is only one additional maintenance task for Pay Period PEP and that is for Benefit rules - Months and accumulators. There is an additional tab in Benefit Rules maintenance to maintain pay periods for benefits. The benefit rule fiscal months cannot be re-used for Pay Period PEP; new pay period rules for benefits will need to be maintained.

## High Volume Framework

Q5.3.1 What is the significance of High Volume Framework?
Adding the pay period level of results to PEP will significantly add volume to the calculation logic and the number of records produced. There are some real time use cases which demands Projection Scenario to generate around 200 million records. In this type of scenarios the High Volume Framework is recommended.
Current PEP engine captures the calculated results in Employee monthwise and Position monthwise DSOs, which in turn is posted to the Projection Cube using set of DTPs. Instead of capturing the calculated results in one set of DSOs, multiple DSOs (For Employee and Position Records) are introduced to distribute the load and to improve the DTP performance. Currently we provide 3 DSO’s for Employee and Position each. However, any number of DSO’s can be configured. To further increase the performance, the same number of InfoCubes (3 InfoCubes for 3 Employee and Positions DSO’s each) are needed to capture the result. Multiprovider /PBFBI/PPRD_M1 has been created to combine the results.

Q5.3.2 What do you mean by High Volume Projection Kit? What is the difference between High Volume Process Chain with Parallel DTPs and High Volume Process Chain with Sequential DTPs? How to decide which Process Chain should be used?

The High Volume Projection Kit configured with multiple DSOs (3 DSO’s for Employee +3 DSO’s for Positions) can be introduced to distribute the load and to improve the DSO Insert and the DTP performance. To further increase the performance, we can introduce same number of InfoCubes (3 InfoCubes) to capture the result. Multiprovider /PBFBI/PPRD_M1 can be created to combine the results.

In High Volume Projection Kit we are delivering two chains called Parallel and Sequential.

High Volume Process Chain with Parallel DTPs: In this process chain data can be processed parallel and this type of chains recommended using only when the system has multiple back ground process.

High Volume Process Chain with Sequential DTPs: In this process chain data can be processed Sequential (One by One) and this type of chains recommended using only when the system has less back ground process.

If the number of back ground process less(<=5) then it is recommended to use Sequential Process Chain, otherwise use Parallel Process Chain.
The calculated data is stored in a set of 6 DSO’s and 3 Cubes (configurable). The transfer of data from the DSO to the Cube is done through DTP’s (Data Transfer Process).

The difference between the 2 chains delivered is that one chain executes the DTP’s for the 3 DSO’s sequentially and the other executes it in parallel.
The process chain with parallel work process is to be used only if you have the required number of background work process supported in your system. Otherwise, you should use the process chain with sequential DTP’s.

For example, if you have 3 DTP’s, a minimum of 9 background work processes are required for it to allow parallel processing since each DTP needs 3 work processes for the best performance. Similarly, for more number of DTP’s , i.e. more number of DSO’s and Cubes configured, the number of background work processes required will also change. Therefore, if the required number of work processes is not available, sequential process chain has to be used.
Pay Period Projection Scenario Sequential
/PBFBI/PPRD_PROJ_S01
Pay Period Projection Scenario (Parallel)
/PBFBI/PPRD_PROJ_01

Q5.3.3 How to configure the High Volume Projection Kit and when to use it?

The High Volume Projection Kit can be configured in SPRO in BW and the steps as follows.
SPRO->SAP Reference IMG->Public Budget Formulation (PBF)->Projection Calculation Configuration->Process Chain Configuration->Maintain Pay Period Process Chains

High Volume Framework can be used when the expected set of salary records for employee or position is in large number i.e. if the volume of data expected after calculation is high. This is required to enhance performance.

Q5.3.4 What happens if the High Volume Projection Kit is configured and used for small Projection Scenarios?
The High Volume Projection Kit can be configured for small Projection scenarios. The High Volume Projection Kit is required to aid performance if the volume of data is high. For small projection, the volume of the resultant data is low DTP performance may be bad.

Q5.3.5 What is the impact of configuring both the High Volume Process Chains in SPRO Configuration?
Since both Process Chains (Sequential DTPs and Parallel DTPs) are referencing the same set of DSOs and Cubes, it may result in locking conflict. So both high volume process chains shouldn’t be configured.
By default, Process Chain with Sequential DTPs should be configured.

Q5.3.6 How to decide the package size and the number of work processes to be used for the High Volume Projection Kit?

The package size for a projection should be defined in such a way that the resultant set of records does not cross 1 lakh. The result set depends on several factors such as period duration, number of benefits configured, number of periods for which the benefits are configured etc. Therefore, keeping this in mind, the package size should be determined.

# Attrition and Backfill (A&B) PEP

Q6.1.1 What are the pre-requisites to execute an Attrition and Backfill Scenario?

A Flexible Pay Period reference projection should exist and the required Attrition & Backfill rules need to be maintained and configured in A&B Group.

Q6.1.2 What is a Pay Period reference projection? How is a Pay Period reference projection created?
A Pay Period reference projection is created by executing a Pay Period projection with the ‘Save Master Data’ checkbox selected. This is a pre-requisite for executing an Attrition and Backfill projection.

Q6.1.3 What is the difference between an Attrition Rule and an Attrition and Backfill Group Rule
The attrition rule consists of selection criteria, such as the desired FM dimensions, Employee Group, Personnel Group, Pay Scale Group, Job, and so on. Once the selection criteria are complete then the pay year and period and attrition rate is entered. This combination of data represents an attrition rule.
An Attrition and Backfill Group rule consists of Attrition rules and can include backfill criteria. The A&B Group rule is specified on the A&B Projection screen and will be used when the A&B projection executes.
Several attrition rules can be used in one attrition and backfill group rule. There are no checks or warnings for attrition rules that may have overlapping selection criteria. If there is overlap, the attritions will be calculated as per the configured group rules and attrition rules.
When the A&B projection runs, all the rules in the group will be applied.

Q6.1.4 What are the different scenarios that can be created using A&B configuration screens?
a) Only Attrition (represents work force reductions)
b) Only Backfill (represents work force increases, can represent a hiring event)
c) Attrition & Backfill (represents work force reduction with future backfill by actual headcount or a percentage of attrition)

Q6.1.5 How does A&B calculation work?

• The projection has a qualifying set of employees and the attrition rate is applied based on the attrition rule(s).
• Note that ONLY Employees can be attritioned; positions are not considered for attrition
• Once an employee starts an attrition at a specific pay period, the attrition continues each pay period thru the end of the projection.
• Create attrition records with the calculated counts and amounts multiplied by -1 to convert to negative counts and negative amounts
• All key figures should be posted with negative values to nullify with the Reference Projection records, meaning negative delta records will be created.
• Determine the backfill position, counts and amounts and starting pay period as per the backfill rule.
• Note that ONLY Positions reflect backfills; employees are not used for backfills.
• Once a backfill position starts at a specific pay period it continues thru the Backfill Position End Date (Backfill Position MD) or the end of the projection whichever is earlier.
• Step date logic for pay grade increases will be applied thru the end of the projection.
• Create backfill records with counts and amounts as delta records. These will be positive counts and positive amounts.
• Write all delta records to the A&B Projection cube, /PBFBI/PPRD_C4.

Q6.1.6 How do you analyze the A&B Result?
A&B results should be reported along with its corresponding Pay Period Reference Projection (Parent Projection). Then you can easily notice the Attrition of Employees and Backfill of Positions. Multiprovider /PBFBI/PPRD_M1 contains the Pay Period and A&B Projection cubes.

Q6.1.7 How does Parallelization work for Attrition and Back Fill (A&B) Scenarios?
Employee master data snap shot details are read based on the reference pay period projection.
Then attrition rule details are read from the input A&B group id.
Employee master data is filtered out based on the FM dimension of each attrition rule.
Employees belongs to each rules are processed in parallel. That means, each attrition Rule will be processed in Parallel.
If any Attrition Rule qualifies more employees and results in Employees Attrite count being greaten than the Package Size maintained in the SPRO,.
then it splits the total attrition employees into packages and processes each package sequentially.

Q6.1.8 What is the significance of the A&B BAdI?
PEP calculations have a fundamental algorithm to calculate vacant position count. The PEP calculation engine first determines the number of Employees for a Position. It then determines the number of vacant positions as follows:

• Position Vacant Count = Authorized Count (Position Master Data) – number of employees.

When applying Attrition rules to PEP results, Employees are always attritioned; vacant positions are not considered by attrition rules. Therefore while the Attrition rule would reduce the number of employees, it would also increase the number of vacation positions as per the PEP algorithm.  For example, if there were an authorized count of 10 and there are 5 employees, then there are 5 vacant positions. Using the PEP algorithm, if 2 employees are attritioned, then the vacant count would become 7.

This behavior may not be desired, especially if Backfill rules are provided to determine if/when backfill positions would be planned. Therefore a Business Add-in (BAdI) was developed that will cause PEP Attrition and Backfill scenarios to not increase the position vacant counts as a result of attrition. To activate the BAdI logic simply activates the PBF Enterprise Business Function /PBFBI/BF_PPRD_ANB_VACANT_ADJ. For more details see the Solution Manager topic Business Add-in (BAdI) for Attrition and Backfill (optional).