- 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.
Filtering based on projection screen criteria
Q1.1.1: When determining which positions/employees to include in a projection run, the systems uses the configuration settings and dimensions you select in the projection run and then searches the employee and position records to find any records that match within the projection run start and end date, correct? So, if an employee/position has some records that match during the time period and some that do not match, will the employee/position will be included in the PEP results?
Selection Criteria from the Projection Screen includes: FM Dimensions and other 7 fields (Job, Pay Group, ES CAP, Employee Group, Employee Subgroup, Personnel Area(only for Emp), Personnel SubArea(Only for Emp)). All the Employee and Position Master Data Objects which fulfill the selection criteria and falls within the Projection Start And End Dates will be qualified for the PEP Calculation. If an employee changes to a different employee group, or there is a fund center change, only those records that match the MD at the time of execution will be included in the projection results.
Q1.1.2: Does the system also search the Employee Allocation and Position Allocation DSO's to determine if the position/employee matches the dimensions selected and should be included in the projection run?
Yes, the PEP engine looks into Allocation DSO for qualifying the Master Data Objects which are allocated across different FM Dimensions. As the Employee and Position master data InfoObject holds only Home Funding details, if the Emp/Pos are allocated across other FM dimensions, then those objects should be included.
Q1.1.3: After determining to include a position/employee in a projection run, when calculating the amounts and other fields does it only include the records that met the dimensions selected and will only calculate values for the time period with those matching records? For instance, the selection criteria on the projection run specified fund A with projection start date 7/1/2011 and end date 6/30/2016. Position 1000 had fund A assigned from 7/1/2011 to 12/31/2011 and then had fund B assigned from 1/1/2012 to 12/31/9999. The PEP calculation engine would only output values for the 7/1/2011 to 12/31/2011 time period, correct
Yes, the PEP Engine will post theresult only for Fund A (since it’s a part of Selection Criteria) and Fund B is filtered.
Step Date Calculations
Q1.2.1: If a position is vacant, does the PEP engine use the pay scale level table to determine pay level increases?
Step Calculation and Benefit Calculation works exactly the same way for Positions and Employees. For fixed salary Employees and Positions, meaning the Salary Override flag is set on in the Employee / Position MD, there won’t be any grade change. But amounts will increase annually based on the fixed rate maintained in the pay level master data.
In case if you don’t want step calculation for positions, you can set the data as described below:
- Change Position as fixed salary position (by setting salary override checkbox to on/active)
- Don’t maintain any value for fixed rate in the Pay Level master data for its corresponding Pay Level
Finally, the PEP Engine will not compute step increases if the Promotion Date for the Employee or Position is maintained as blank. So if the Promotion Date is blank, then what ever the current level is assigned will be used for the full duration of the projection.
Q1.2.2: If Pay Scale and/or benefits are established for a job and a position and an employee, which data is used by the PEP engine?
The PEP engine first looks at the employee level for pay grade info, benefits, etc. If these are not maintained at the employee level then it looks at Position. If they are not maintained at Position, then it looks at the Job. So you can think of Job having the default values but they can be overridden by Position, and Job and Position can be overridden by Employee.
Prior to PBF 8.0 if an Employee and its corresponding Position were assigned to different Jobs, the PEP engine treated this as a data consistency error and the results would not be calculated. From PBF 8.0 and onward, this scenario is supported by PEP and the results will be calculated. The data defined at the employee level would be used, following the same logic that is stated above.
Q1.3.1 If a Position A is maintained with Authorized count of 5. When loading Employees due to either wrong HR system or whatever, 7 employees are assigned to the same Position A. What will be the result of the calculation?
If the employee count is more than authorized count then this will be an overfilled scenario. PEP engine will post negative amounts.
Q1.3.2 Is there is a way to increase the number of Vacant Position count through any of the projection screens, without changing the Position MD?
There is no way to increase Position Vacancies in PBF 8.0 through the Projection Screen or the What-if Projection screen. This functionality is supported in PBF8.1 with Attrition and Backfill Projections. Also the Flexible Source feature in Pay Period PEP allows Employee and Position MD to be provided in DSOs instead of the Employee and Position InfoObject master data.
Q1.4.1 How can the Projection Run Status be tracked after hitting the Calculate Button?
The status of the PEP execution is shown in the Projection Monitor. Each projection scenario is tracked by a unique ID, called the Projection ID. The Projection Scenario Queue will detail the Projection ID, Run Type (New Run or a Re-Run), user and time of queue entry.
An entry in the queue is actually waiting for a process chain to be available for execution. The moment a chain becomes available, the projection ID disappears from the queue and will then be moved to the status monitor. This means that the entry is now in process. The status monitor will display the projection ID and the process chain. From the Process Chain, the user can then identify the Info Provider that will eventually hold the Projection ID results.
The execution (irrespective of successful or failed) once completed, will no longer be displayed in the status monitor. The user will have to switch to the previous executions screen by clicking Go to Previous Runs.
Q1.4.2 If Projections have been submitted but they never show as running in the Projection Monitor what could be the cause?
There is a program /PBFBI/PEP_POOL that needs to be scheduled to run periodically in the background that will launch projections. If the program is not scheduled it can be run manually to launch a projection.
If the job log to /PBFBI/PEP_POOL states that ‘no chain is available’ to launch a projection, then it could be that a projection failed to complete and has the process chains still locked. If this is the case the following can be done to clear the process chain:
• Table /PBFBI/PRJ_STTUS has the list of current projections and process chain. Execute transaction SE16 for table /PBFBI/PRJ_STTUS to see if
there is an entry for any of the PEP process chains. If there are some with the runtype of N (new run) but you know for sure that the projection is no longer running, then it could be that the execution failed unexpectedly and the error status did not get set. You should check with the user listed in the table to confirm this is the case before clearing the table entry!
• To clear the table entry, execute transaction SE37, enter function module /PBFBI/PRJ_MANUAL_OK and execute (press the Wrench icon or press F8). Click on the puzzle piece icon to enter data. The following data is required:
- Projid and Pchain as per the table entry in table /PBFBI/PRJ_STTUS
- Proj_stat = R
• Press Execute
• After the function runs you can check the Results table. You should see 2 messages stating that the projection ID was successfully inserted entry into Historical Table and that the Status table entry was deleted. The Process chain now be available for further runs.
Q1.4.3 If a projection executes and there are no results produced, meaning no records are saved in the projection cube and there are no error messages, how do you find the problem?
- Prior to PBF Release 8.0 the PEP scenario allowed the Vacant Flag on the selection screen to be blank. However the PEP engine requires Vacant Flag to have a value. If running PBF prior to release 8.0, check that the Vacant Flag has a value.
- PEP requires the appropriate Master Data to be in place to support the selection criteria entered with the PEP projection. The required master data includes:
• The Employment Status in the PBF Global settings table needs to have a value. This value is used by the PEP engine to determine which employees are Active. Use PBF IMG node Maintain PBF Global Settings to check this setting
• There needs to be at least one employee and one position with the active status setting
• Maintain values for salary relevant fields such as Pay Level, details, FTE period, Performance Start Date and Performance Period, salary percentage etc. properly.
• There should be a corresponding entry in the Pay Table for the given combination of Pay Scale Levels.
• If Auth count =1 and only 1 employee is assigned means there is no vacant position. If the Vacant Flag on the selection criteria is to only report vacant positions, the PEP engine would not produce any results in this scenario.
• Prior to PBF release 8.0, Position and its corresponding employees must be assigned for the same job. Otherwise such employees will not be considered for PEP calculations.
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).
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 / Scenario||Fiscal Period PEP||Pay Period PEP|
Maintain Process Chain Configuration
Configure Fiscal Year Variant
Maintain Process Chain Configuration
Configure Fiscal Year Variant
Configure Pay type(s)
Upload Pay Table
Maintain Pay Period Process Chains Configuration
|Results Postings||Calculates 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 Projections||Supported||Not Supported|
|Distribution Rule||Supported||Not Supported|
|Flexible Source Selection||Not Supported||Supported|
|Attrition and Backfill Projections||Not Supported||Supported|
|Re-run Functionality||Supported||Not 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.0||Functionality / Usability Description|
|Versioning of Master Data / Save Master Data Option||Allows 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 Calculations||PEP 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 Interdependency||Supports Employee and its corresponding Position if they are assigned to different Jobs. In PBF 7.1 this was considered an error|
|Multiple Currency||Supports 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 Projections||Allows additional scenarios to be executed based on a previously run projection (reference projection) reusing the master data from the reference projection|
Q3.1.3 What functionalites are provided by the PEP What-if Projections?
PEP What If Projections were introduced in PBF 8.0 and are only available with Fiscal Period PEP. They are not supported by Pay Period PEP. The following table outlines the functionality provided by What If Projections.
|Feature||Functionality / Usability Description|
|What If Projection Scenario||Allows creation of Projection Scenarios within the subset of a previously run Reference Projection. The MD from the Reference Projection is used instead of the Employee/Position InfoObject MD|
|Supplementary Amounts and Rates||Similiar to existing Projections, it allows to increment Salary and Benefits with additional amounts or percentages|
|Overwrite Pay Level MD||Allows to override pay scale details maintained in Pay Scale Level MD. Step Month, next Pay Scale Group and Next Pay Scale Level can be overridden for a particular What If Projection|
|Re-allocate Funds||Allocation details maintained in the Employee and Position MD can be re-allocated across different FM dimensions for the specified duration|
|Add new Employee/Position Benefits||Additional benefits can be added to individual Employees / Positions for a particular What If Projection|
|Remove existing Employee/Position Benefites||Existingl benefits can be excluded from individual Employees / Positions for a particular What If 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
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:
- 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.
Flexible Source for Employee / Position MD
Q5.2.1 What do you mean by Flexible Source? How do you create a new Source?
Flexible Source provides an option to the users to assign DSOs (Direct update, Standard) as a source of master data for employees and/or positions. The pre-requisite with this functionality is that users will have to create the DSOs and queries similar to the PBF delivered queries on the source DSO.
There are two template DSOs that are delivered in PBF that can be utilized to create the new DSOs. DSO structures created should include all the fields of the template DSOs. The Template DSOs are: /PBFBI/PPRDEMP (for employee data) and /PBFBI/PPRDPOS (for position data).
Queries should be created on the new DSOs using the query templates. There are two sample queries that are delivered in PBF: /PBFBI/DSO_I02_Q0001 (for employee data) and /PBFBI/DSO_I01 (for position data).
Users can upload employee and/or position master data to standard/direct update DSO and create the required queries on top of these DSOs and maintain in the global configuration along with an identifier called source id.
The above details need to be configured in the IMG in BW (transaction SPRO).
Follow IMG nodes ->SAP Reference IMG ->Public Budget Formulation(PBF)->Projection Calculation Configuration->Maintain Master Data DSO for Employee and Position
Click on New Entries and enter the details as mentioned in the screenshot including source ID.
- Alternate Master Data Source (DSOs) can hold only different versions of the master data. If you add new set of employees or positions which don’t exist in the Master Data Object, then the master data will be created automatically by the system upon Projection execution. This is a standard BW behavior, when the records are generated in the InfoCube thorugh DTPs, then the master data will be created.
- You can’t maintain the description for Employees or Positions in the DSOs, so if you want to add new set of employees or positions which don’t exists in the Master Data Object then you have to create those employees/positions in the master data with description.
Q5.2.2 What are the different types of DSOs that can be used as an alternate source?
Both Standard and Direct Update DSOs are supported, but it’s advised to use standard DSOs since data loading will be easier through DTPs.
Q5.2.3 Why can’t Master Data InfoObjects be used as an alternate source?
Because, Employee and Position Master Data references /PBFBI/EMPLOYE and /PBFBI/POSTN objects in all BW objects. Also the system generated field names (/BP09/S_EMPLOYE and /BP09/S_POSTN) are referenced inside the PEP Engine code. If you create a copy of the master data objects, then the referencing field name will be different. For Example, Field name of ZEMPLOYE is not same as /BP09/S_EMPLOYE.
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
Pay Period Projection Scenario (Parallel)
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).