HR2008_2emea

© 2008 Wellesley Information Services. All rights reserved.

The Fundamentals of Customizing SAP Payroll with Schemas, Rules, Functions, and OperationsMike TimmIntegrated Consulting Group

2

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

3

What We’ll Cover …

• 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

4

Overview of Payroll and Payroll Objects

• First, select “Release payroll”In this step the payroll area and payroll period to be processedare selectedThe payroll control record is set to allow payroll processingEmployee master data records are locked

• Next, select “Start payroll,” enter screen parameters, and launch the payroll process

Payroll processes generating wage typesAssignment to company and cost center are doneCheck the results by viewing the remuneration statement

• Finally, select “Exit payroll”The payroll control record is set to finalized, allowing for additional processing such as posting to accounting and third-party remittanceEmployee master data records are unlocked for maintenance

5

Overview of Payroll and Payroll Objects (cont.)

• Payroll screen parameters include a schema• The schema determines how the payroll program should be

utilized

Schema

Function

Rule

Operation

Payroll Program(Driver) contains

Function modules

Operation modules

6



7

Schema Introduction and Configuration

• Schemas control the payroll processing stepsProvide the instructions for payrollSupply the logical flow of data in, calculation performance, anddata outCustomizable and flexible to meet business requirementsHowever, configuring has a feel of mixing table configuration and programming together

• The payroll program contains code that is called by the schemaThe schema utilizes the snippets of code within the payroll program for calculations, etc.Schemas control the use of functions

8

Schema Introduction and Configuration (cont.)

• Transaction code PE01 is used to maintain schemas• Copy SAP standard schemas to a customer name range

Copy standard payroll schema U000 and then only maintain the new Z000 schemaReduces issues when SAP provides updates to a standard schema with support packages or upgradesWhen 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

9

Schema Introduction and Configuration Example

• We’ve 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

Customized rules

Customized function

10

Schema Introduction and Configuration Tips

• 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

11



12

Overview of Function Use in Schemas

• Functions are snippets of code found in the payroll program thatare called by the schema

Function may or may not have parameters set in the schema —it isn’t always a requirementYou can determine the available parameters by using the F1 (Help) key when you put your cursor on a function in the schema view

• Functions may read:InfotypesProcess rulesProcess multiple tables to calculate wage typesProcess payroll internal tables

• Version management is available

13

Function Use in Schemas Example

• 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

Standardfunctions

Customfunction

14

Function Use in Schemas Example (cont.)

• Maintaining or displaying the functions is done using transaction code PE04

You may configure the characteristics of the function and available parameters

Available for countries

Parameter 3Parameter 4

Using F1 (help) next to RAB in the schema

15


• 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 receivedThis 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 don’t receive the error message for specific absence types

Copy RAB to ZRAB and modify ZRAB using transaction code PE04

Config change

16


• SAP standard RPCMAS09_FURABCalls function HR_CONVERT_2001_INTO_AB_TECH

• ZRPCMAS09_FUZRABThe function is identical except that the custom version calls function ZHR_CONVERT_2001_INTO_AB_TECHAnd we also define a custom operation, which we’ll look at later

Code change

17


• ZHR_CONVERT_2001_INTO_AB_TECHzpermitabsences contains absence types that won’t cause errorsIf the absence type is found in the custom table, then no error and allow continued processingIf the absence is not found in the custom table, then error (follows SAP standard)

Additional code

Custom table absence type lookup

18

Summary of Function Use in Schemas

• We’ve 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 configurationLater, we’ll 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, doesn’t mean you should

19



20

Rule Introduction and Configuration

• Rules provide the logic flow of processing payrollThey are attached to schemas and executed during payroll processingFunctions in the schema process a ruleRules contain operations that perform calculations or other decision logic

• Configuring rules is not necessarily intuitiveConfiguration has a feel of mixing table configuration and programming together Not directly date delimited like table entries, but options are available to work around thisPlacement of the rule in the schema needs to be carefully considered

21

Rule Introduction and Configuration (cont.)

• Highly customizable to meet business requirementsRules may make decisions on a variety of objects such as employee group/subgroup, personnel area/subarea, etc.Wage types contain splits that link related data, such as WPBP, to it, and should be considered when developing rulesWage type specific or genericHard-coding values should be avoided, and table entries such as constants should be used insteadVariables may be set and used for later processing to trigger other rules to perform specific tasks

22


• Rules are configured in transaction code PE02Display or maintain rulesMake decisions based on objects such as employee group/subgroup or wage type processing classOperations are set within the rule

23


• Transaction code PE02 is used to display/maintain rule U010Multiple operations are performing steps for the desired output

Indicates decisionAdds wage type to

output table

24

Rule Introduction and Configuration Example 1

• 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 ten 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 daysTen payroll days — five inactive days — three absence days

We resolved this by creating a custom operation %TACT, which we’ll cover laterAnd, modifying the standard proration

25

Rule Introduction and Configuration Example 1 (cont.)

• 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

26

Rule Introduction and Configuration Example 2

• In this example, let’s 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

27


• Configuration requires table updatesThe creation of time wage types, such as regular, overtime, and doubletimePremium wage types and valuesPremium codes

• Configuration also requires schema and rules developmentModification of schema UT00 by exchanging a rule and adding a new ruleModification of rule X930Creation of rule ZMUL

28


• Regular, overtime, and doubletime wage types are createdThe wage types are available in Infotype 2010

• Shift and lead premium wage types are createdWage types are behind the scenes and not available in any Infotypes

29


• 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 IDs — one for each

of the shifts

30


• 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

31


• Schema ZUT0 is a copy of delivered UT00Two modifications, the first being Z930

Z930 replaces X930

32


• 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 calledIf the payroll area is 03, rule ZPRE is called to start the premium code dynamic valuation

33


• Rule ZPRE performs a couple decisions to verify required data fields are populated

If the amount is not zero, continue directly to the premium ruleIf the amount is zero, do hours exist in Infotype 2010 Number ofhours field?If the amount is zero and the Number of hours field is zero, then use the hours from the Number field

34


• 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 aspart of the premium process

• The number field is brought from the time wage type to the generated premium wage type

35


• 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

Shift 3 wage typeLead wage type

36


• Schema ZUT0 is a copy of delivered UT00Two modifications, the second being ZMUL

ZMUL is added after valuations are performed

37


• Rule ZMUL uses the C3 Split added in ZPR1 to determine which percentage the premium wage type needs to be processed with

38

Example: Processing During Payroll

• Let’s 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

39

Example: Processing During Payroll (cont.)

• Time wage types are loaded in Infotype 2010• Premium code L3 is assigned to each entry

Lead premium of $1.50 per hourShift 3 premium of $3.00 with time-type reference

40


• Process payroll with the log checked

• Expand the P2010 node to see the detail

41


• The Input table contains the three entries from Infotype 2010• The wage type, hours, and premium number are all pulled in and

will process through the rule Z930

42


• 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

43


• 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

Split C3 values set by rule ZPR1

44


• Move further down in the payroll log

• Expand the PIT ZMUL tree

45


• 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

46


• 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

47


• The two 0412 wage types have had the rate and amount recalculated

C3 15 changed from $3.00 to $4.50C3 20 changed from $3.00 to $6.00

48


• The output remuneration statement shows the correct hours, rate,and amount for each of the time and premium wage types

RegularOvertimeDoubletimeCombined

49



50

Operation Use in Rules

• 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 stepsManipulate one wage type at a time and store the wage type in an output tableMay perform decisions within the rule to determine a path to follow — personnel area, employee subgroupUp 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 neededOperations allow for parameters to determine how the operation should behave

• Version management is available

51

Tips for Creating a Custom Operation

• 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.

52

Maintaining and Displaying Operations

• Maintaining or displaying the operations is done using transaction code PE04

You may configure the characteristics of the operation and available parameters

Available for countries

Parameters

Using F1 (help) next to PPAR in the rule

53

Example: Operation Use in Rules

• 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 periodThe operation returns a Y or an N depending on whether the Infotype 0000 action is the same as the parameter setThe work week contains 40 hours and runs Monday through FridayThe allow absence occurs on Friday, and the LOA action occurs on Wednesday

54

Example: Operation Use in Rules (cont.)

• 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 andTuesday and eight hours of absence for Friday, a total of 24 hours for the week

TSAU = unpaid absenceTSAP = paid absenceTSAX = paid holiday

55

Example: Operation Use in Rules (cont.)

• %TACT is used only in the United States• The parameter input is two characters with an output of one

character

56



57

Putting Them All Together

• The example we will be stepping through is based on the schema, function, rule, and operation examples we discussed previously

• We’ll 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

58

Putting Them All Together (cont.)

• Infotype 0008 — Basic PayEmployee is paid 1,711.9106 per 40-hour work week

• Infotype 2001 — AbsencesAbsence entry is made prior to LOA actionAbsence 0200 is located in zpermitabsences

59


• Proration in the original period was eight hours of absence and 32 hours of attendance at an hourly rate of 42.7978 (salary dividedby 40)

Eight hours of absence = 342.3832 hours of attendance = 1,369.53

• Infotype 0000 — ActionsAn LOA action is created retroactively into the periodThis effective date of the action causes the previously entered absence to be in an inactive period

60


• Under standard SAP, the absence in the inactive period will cause an error

61


• However, custom function ZRAB allows processing, since the absence type 0200 is found in the custom table zpermitabsences

62


• The payroll period runs from 09/09/2007 to 09/15/200709/09 and 09/15 are days offThus, with an LOA effective date of 09/12, the employee has:

Two active days (09/10 and 09/11)Three inactive days (09/12, 09/13, 09/14)

Company policy is that the eight paid absence hours are not recouped

• During the retro calculation for the period:The employee should be paid for the two days of attendanceAnd, the employee should still be paid for the day of absence after the LOA began

63


• 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 period40,000 is equivalent to 40% of the period or two days

The second /801 is the inactive period20,000− is equivalent to −20% of the period, or one day

Two entries exist for the salary found in Infotype 0008Each salary entry will be multiplied by each /801

64


• 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

65


• The custom proration rule and operation we created earlier allowfor the correct proration

• Two /801 wage types flowed into the custom rule /MLPHowever, only the /801 from the active period came out with a valueIn the active period /801, as with standard SAP proration, 40,000 is equivalent to 40% of the period, or two days

66


• 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%

• Two entries exist for the salary found in Infotype 0008Each salary entry will be multiplied by /801

67


• 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

68



69

Resources

• Schema, function, rule, and operation help at http://help.sap.comSAP ERP ERP Central Components SAP ERP Central Component Human Resources HR Tools

• Program RPDSYS00 or transaction code PDSY for HR documentation about specific objects

70

7 Key Points to Take Home

• Schemas control the logical flow of data during payroll processing

• Do not change SAP-delivered schemas, rules, functions, or operations — make 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

71

7 Key Points to Take Home (cont.)

• Custom functions or operations should be created when standard functionality does not exist or configuration would be more timeconsuming

• Functions and operations have version management

72

Your Turn!

How to contact me:Mike Timm

[email protected](215) 667-8429

73

DisclaimerSAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver®, Duet™, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

Documents

HR2008_2emea