The Fundamentals of Customizing SAP Payroll With Schemas, Rules, Functions, and Operations
The Fundamentals of Customizing SAP Payroll With Schemas, Rules, Functions, and Operations
The Fundamentals of Customizing SAP Payroll With Schemas, Rules, Functions, and Operations
In This Session
Develop an understanding of SAP Payroll schemas, rules, operations, and functions Step through an actual payroll process to see examples of each object Learn how to create and modify schemas and rules Leave with advice to avoid potentially costly mistakes when developing custom schemas, rules, operations, and functions Explore functions and operations, and why it may be more efficient to develop custom operations to address functionality gaps
1
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
Next, select Start payroll, enter screen parameters, and launch the payroll process
Payroll processes generating wage types Assignment to company and cost center are done Check the results by viewing the Remuneration statement
Payroll screen parameters include a schema The schema determines how the payroll program should be utilized
Payroll Program (Driver) contains Function modules Schema Function Rule
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
Where Transaction code PE01 is used to maintain to FIND it schemas Copy SAP standard schemas to a customer name range
Copy standard payroll schema U000 and then only maintain the new Z000 schema Reduces issues when SAP provides updates to a standard schema with support packages or upgrades When making an update to the custom schema, make a back-up copy first since there is no version management Makes it easier to reverse changes or scrap all the changes quickly if needed
Weve made a copy of standard SAP schema UT00 and called it ZML2 to handle customized time data processing The payroll driver uses ZMLT (copy of U000) and calls ZML2 instead of UT00
Compare schemas with menu path Schema Compare after displaying the schema in transaction code PE01 Program RPDASC00 outputs a schema with differing levels of detail set by the user
Tip
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
10
Functions are snippets of code found in the payroll program that are called by the schema
Function may or may not have parameters set in the schemait isnt always a requirement You can determine the available parameters by using the F1 (Help) key when you put your cursor on a function in the schema view
In our example schema ZML2, we can see the use of standard and custom functions The functions request the snippet of code from the payroll program
Standard functions
Custom function
12
Parameter 3 Parameter 4 13
Standard SAP function RAB pulls all absences in from Infotype 2001 and assigns work center split indicators
When an absence appears in an inactive period (after termination, LOA, etc.), an error is received This may be changed with Parameter 4, but this allows all absences in an inactive period to pass without an error message
Our goal is to make it so we dont receive the error message for specific absence types
Copy RAB to ZRAB and modify ZRAB using transaction code PE04
Config change
14
ZRPCMAS09_FUZRAB
The function is identical except that the custom version calls function ZHR_CONVERST_2001_INTO_AB_TECH And we also define a custom operation, which well look at later
Code change
15
ZHR_CONVERT_2001_INTO_AB_TECH
zpermitabsences contains absence types that wont cause errors If the absence type is found in the custom table, then no error and allow continued processing If the absence is not found in the custom table, then error (follows SAP standard)
Additional code
16
Weve been able to use an existing function to make quick and easy modifications to handle business requirements
Now we are able to process a specific set of absence types in an inactive period without errors Other methods were available, but those methods required much more complex configuration Later, well go through an example to show how proration has to be modified to handle these absences
Functions are not as difficult to review and understand as most people first think Use custom functions only when existing options will not meet business requirements
Just because you can, doesnt mean you should
17
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
18
20
21
Indicates decision
22
In the ZRAB function example, we made it so a select number of absences process through an inactive period without causing an error A side effect was that the proration became skewed because of the absence
If the payroll period is then days, the person is inactive for the last five days and has three absences in the last three days The standard proration returned two active days Ten payroll days five inactive days three absence days We resolved this by creating a custom operation %TACT, which well cover later And, modifying the standard proration
23
Z000 US accounting schema for RPCALCU0 Z000 calls schema ZML3 for the gross calculation
Rule /ML4 uses custom operation %TACT to look for action UB If the action is UB, returns a Y, otherwise N When N, the proration follows standard SAP proration logic When Y, the proration is changed to allow for the ZRAB function allowing absences during an inactive period 24
In this example, lets assume that we are using Infotype 2010 to process time from an external system If we were to use standard premium code functionality, multiple premium codes would have to be created for each type of time (standard, overtime, double time, etc.) to generate the appropriate premium rate Instead, we will use standard configuration tables and three custom payroll rules to allow only one premium code to be entered and generate the appropriate premium rate
25
26
27
Premium codes are created in table T510P Amounts are not assigned to the premiums Use of the Premium ID could be used to reduce the number of premiums even further Premium No. could be LD with three Premium IDsone for each of the shifts
28
Wage types are added and assigned a value in table T510J Payroll rules will use the premium code entered in Infotype 2010 to generate a premium wage type The premium wage type then receives the value from this table Using the PMod (payroll modifier set in rule UMOD) grouping, different values may be generated for the same wage type
29
30
Rule Z930 replaces standard rule X930 in the schema The rule makes a decision on the payroll area
If the payroll area is not 03, standard rule X930 is called If the payroll area is 03, rule ZPRE is called to start the premium code dynamic valuation
31
Rule ZPRE performs a couple decisions to verify required data fields are populated
If the amount is not zero, continue directly to the premium rule If the amount is zero, do hours exist in Infotype 2010 Number of hours field? If the amount is zero and the Number of hours field is zero, then use the hours from the Number field
32
Rule ZPR1 is where the premium code attached to the time wage type in Infotype 2010 is used to generate a premium wage type and to add Split C3
The SETIN 3 variable will be used in the new rule ZMUL added to schema ZUT0
The rate and amount are zeroed since these will be calculated as part of the premium process The number field is brought from the time wage type to the generated premium wage type
33
In the case of the premium L3, the Lead wage type is generated in addition to the Shift wage type
The Lead wage type does not have the C3 Split set since the rate does not change based on the type of time
34
Rule ZMUL uses the C3 Split added in ZPR1 to determine which percentage the premium wage type needs to be processed with
36
Lets step through example 2 processing in payroll We will use a single premium code, L3, and dynamically generate the premium wage types and rates End users follow the same process as they would whether this was implemented or not
37
Time wage types are loaded in Infotype 2010 Premium code L3 is assigned to each entry
Lead premium of $1.50 per hour Shift 3 premium of $3.00 with time-type reference
38
The Input table contains the three entries from Infotype 2010 The wage type, hours, and premium no. are all pulled in and will process through the rule Z930
40
Each wage type processes through Z930 individually and generates wage types 0413 and 0412 Wage type 0412 is generated with the C3 Split set when wage types 0401 and 0402 process
Wage type 0401 sets Split C3 to 15 and 0402 sets Split C3 to 20
41
The input processes through rules Z930, ZPRE, and ZPR1 and produces the 0412 and 0413 wage type output
Note the C3 value of 15 and 20 for two of the 0412 wage types
42
Where to FIND it
The Input table shows each of the 041x wage types with a rate from table T510J Two wage types still contain the C3 Split set by rule ZPR1
44
The wage types without a C3 Split are added to the Output table without further processing The two wage types with a C3 Split process through ZMUL
45
The two 0412 wage types have had the rate and amount recalculated
C3 15 changed from $3.00 to $4.50 C3 20 changed from $3.00 to $6.00
46
The output remuneration statement shows the correct hours, rate, and amount for each of the time and premium wage types
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
48
Just like functions, operations are snippets of code found in the payroll program that are called by a rule Operations perform calculations or other data manipulation steps
Manipulate one wage type at a time and store the wage type in an output table May perform decisions within the rule to determine a path to followpersonnel area, employee subgroup Up to six operations may be entered on one line of a rule and you have the option of sequential rows allowing for more operations when needed Operations allow for parameters to determine how the operation should behave
Use standard SAP routines when possible Follow SAP standards when creating new operations Do not hardcode values in operations; look up the values in tables allowing for easier maintenance and date effectivity Variables seem to get overlooked and need to be cleared so they are not carried along Make sure to include error handling that provides useful feedback Do not sort internal tables used in the main payroll driver since the main program might be expecting the internal table to be in a specific order. If needed, copy data to a new internal table for use in custom operations or functions.
Tips
50
Parameters 51
Following our example of allowing specific absences to process through payroll without error, we had to create operation %TACT Operation %TACT allows for proper proration when the absences are in the inactive period
If we had not modified proration, the absence in the inactive period would cause a reduction in hours paid during the active period The operation returns a Y or an N depending on whether the Infotype 0000 action is the same as the parameter set The work week contains 40 hours and runs Monday through Friday The allow absence occurs on Friday and the LOA action occurs on Wednesday
52
Standard proration will end up paying eight hours of attendance for Monday and Tuesday combined and eight hours of absence for Friday, a total of 16 hours for the week Our goal is to pay eight hours of attendance for both Monday and Tuesday and eight hours of absence for Friday, a total of 24 hours for the week
53
%TACT is used only in the United States The parameter input is two characters with an output of one character
54
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
55
The example we will be stepping through is based on the schema, function, rule, and operation examples we discussed previously Well start by looking at the entries in the employee master data and then follow them through the payroll log Points where the custom logic differs from the standard SAP logic will be identified Payroll periods are a week with five eight-hour days The employee was originally paid for 32 hours of attendance and eight hours for absences
56
57
Proration in the original period was eight hours of absence and 32 hours of attendance at an hourly rate of 42.7978 (salary divided by 40)
Eight hours of absence = 342.38 32 hours of attendance = 1,369.53
58
Under standard SAP, the absence in the inactive period will cause an error
59
However, custom function ZRAB allows processing, since the absence type 0200 is found in the custom table zpermitabsences
60
61
However, with standard proration, the employee is paid only for one day of attendance and one day of absence
The absence reduced the two attendance days by one
The first /801 is the active period 40,000 is equivalent to 40% of the period or two days The second /801 is the inactive period 20,000 is equivalent to 20% of the period, or one day Two entries exist for the salary found in Infotype 0008 Each salary entry will be multiplied by each /801
62
The first 1,711.91 is multiplied by 40% to generate salary of 684.76 The second 1,711.91 is multiplied by 20% to generate salary of -342.38 Salary nets to 342.38
Remember, the company policy is that the employee receives the two days of salary plus the absence that falls in the LOA period
The employee is missing half the salary amount he/she is owed
63
The custom proration rule and operation we created earlier allow for the correct proration
Two /801 wage types flowed into the custom rule /MLP
However, only the /801 from the active period came out with a value In the active period /801, as with standard SAP proration, 40,000 is equivalent to 40% of the period, or two days
64
The second /801 was reduced to 0% and was dropped, since absences are not included in the proration
In the standard SAP proration, absences are considered and caused the 20%
65
The first 1,711.91 is multiplied by 40% to generate salary of 684.76 The second 1,711.91 does not have a corresponding /801 and is removed
The result is the employee does not have absences during the inactive period recovered from them according to company policy
66
Overview of payroll and payroll objects Introducing and configuring schemas Understanding and customizing functions Introducing and configuring rules Understanding and customizing operations Putting them all together Wrap-up
67
Resources
Program RPDSYS00 or transaction code PDSY for HR documentation about specific objects
68
Schemas control the logical flow of data during payroll processing Do not change SAP-delivered schemas, rules, functions, or operationsmake a customer copy and then modify Make a back-up copy of schemas and rules prior to making changes since there is no version management Schemas and rules are not date delimited like table entries Functions and operations call snippets of code from the payroll program
69
Custom functions or operations should be created when standard functionality does not exist or configuration would be more time consuming Functions and operations have version management
70
Your Turn!
71