搜档网
当前位置:搜档网 › sap_payroll_tutor

sap_payroll_tutor

sap_payroll_tutor
sap_payroll_tutor

Wage Type Processing Basic Concepts Array by Steve Bogner, Managing Partner, Insight

Consulting Partners

Relationship of Payroll Driver, Schema (Functions),

Rules (Operations)

Each country payroll version supported by SAP has a

program called the "payroll driver" that calculates

payrolls. For example, in the U.S., the payroll driver is

RPCALCU0, in Mexico it is HMXCALC0, and in

Canada RPCALCK0. Each one is different, but they

share a common core of functionality. The job of the

payroll driver is to process payroll functions as

specified in a payroll schema. These payroll functions

each perform a specific job, for example - reading data

from infotypes, calculating taxes, and processing wage

types. Some functions process payroll rules. Rules are

a collection of payroll operations. Each operation does

a small unit of work, such as multiplying a wage type’s

number by a rate to get an amount.

Schemas are edited with transaction PE01, and rules

Figure 1– Processing relationships with PE02. Functions and operations are maintained with transaction PE04. To view payroll results,

use transaction pc_payresult (or in earlier R/3 releases go to Tools>Payroll result>Display in the Payroll menu). (See Figure 1.)The standard payroll schema for a country can be derived from table t500l. If the country in table

t500l has an X in the Old Naming Conv field, then the schema is HR Country Indicator plus 000. Otherwise, it is the ISO Code plus 00. So the U.S. has schema U000 and for Mexico it is MX00.

Header and Table Wage Type Concept

When calculating payroll, wage types are read from infotypes and the Time Management cluster and stored in an internal table called the Input Table (IT). (See Table 1.) In ABAP terms, this is simply an internal table. Various payroll functions and operations can read and update data in this table. Similar to ABAP internal tables, there is a header row. That header row defines which row of data can be accessed by the payroll operations. After manipulating the data in the header row, you can save the row back to the IT, save it to another payroll table, or ignore it. In Table 1 there are three wage types, and wage type 2100 is currently in t he header row. After you are

done with wage type 2100, wage type 4200 is moved into the header row.

Table 1 Input Table

Creating Custom Schemas and Rules

Schema and Rule Naming Conventions

Customer modified schemas and rules need to begin with Z. Many customers simply replace the first letter of the standard schema with a Z– i.e., their modified copy of UAP0 becomes ZAP0. But there can be problems with that convention. For example, you might later implement Canadian payroll and need a modified version of schema

KAP0, but ZAP0 is already used for the U.S. For many years, I’ve used a naming convention of Z plus the country identifier and a sequential number for modified rules and schemas. So a modified UAP0 would become ZU01 and a modified KAP0 becomes ZK01.

Editor Documentation

Documentation for the function, operation, schema, and rule editors is available online at https://www.sodocs.net/doc/a617451910.html,. Click on SAP R/3 and R/3 Enterprise and then select your release level and language. Then navigate to the Human Resource s>HR Tools section.

F1 Help

In the schema and rule editors, place your cursor on a function or operation and press F1 to get help text. A schema or a rule’s documentation is available in the editor via the Goto>Documentation menu. In the schema editor, the F4 key shows possible values for each of the four parameters for whatever function is entered on that line. The same documentation – and more – is available via transaction PDSY.

Creating a Test Schema

For testing purposes, it is useful to have a version of the payroll schema that does not care about the control record (transaction PA03) settings. Bypassing the control record lets you run and save the results for any pay period needed, without having to update the control record. There’s no problem with having such a schema around, since the payroll driver does not save payroll results from a schema that ignores the control record in a production system. For examples, I will show you how to create two schemas – ZUA0, which will be used in production and will check the control record, and ZUAT, which ignores the control record and is used for testing purposes only.

First, create a copy of SAP’s schema UIN0 and name it ZUA2. In the schema editor (transaction PE02) enter schema UIN0, and click the copy button, or Schema>Copy in the menu. Enter ZUA2 for the To schema. Then edit ZUA2 and make the CHECK ABR line executable by removing the asterisk in the D column. (See Figure 2.) The CHECK function is commented out by SAP in the standard schema, so you uncomment it here for use in the main ZUA0 schema.

Figure 2 Making the CHECK ABR line executable

Now copy the SAP-standard schema U000 to ZUA1 and comment out the initialization schema UIN0 (Figure 3).

Figure 3 Comment out the initialization schema UIN0

In the schema editor, create the production schema (don’t copy it from anything) in my example ZUA0. Be sure to check the Schema can be executed checkbox. (See Figure 4.) Only executable schemas can be entered into the payroll driver selection screen.

Figure 4 Check the Schema can be executed checkbox

The production schema ZUA0 is a simple one, just two lines. (See Figure 5.) First, you call the initialization schema, and then you call the main calculation schema ZUA1.

Figure 5 Schema ZUAO

Copy schema ZUA0 to your test schema ZUAT. (See Figure 6.) You want ZUAT to ignore the control record, so have it use schema UIN0 for initialization. Remember that CHECK ABR is commented out in UIN0. Therefore, both the production and test schemas now use the same calculation logic in schema ZUA1 – which keeps them in sync.

Figure 6 Copy schema ZUA0 to test schema ZUAT

Your custom rules for these examples will go in a copy of schema UAP0. Copy UAP0 to ZUA3 and add lines for each of the five examples. (See Figure 7.) Edit schema ZUA1 to COPY ZUA3 instead of COPY UAP0 (not shown).

Figure 7 Add lines for each of the five examples

Schema and Rule Documentation

Creating Documentation Objects

Many customizing objects in Payroll can be documented online in SAP. The documentation is added to a transport so that it can be migrated to each client in the development, QA, and product ion environments. There are three ways to document an object online in SAP.

When changing schemas and rules, you can go directly to the Documentation section at the first screen of the editor. Or, while editing, use the Goto>Documentation menu. Either method takes you to an editor. The editor shown in Figure 8 is from the Enterprise release, and the appearance and functions can change from one release

to another. Rule ZUA0 has no documentation.

Figure 8 Editor from the Enterprise release

Typical documentation might look like what is shown in Figure 9. Another U2 heading was added for Modification History.

Figure 9Modification History header added

When modifying wage types, constants, and other data via views in transaction SM30 or the IMG, click on the blue i or Info button for documentation. The current documentation is brought up in display mode. Click on the edit button or press F5 to maintain it.

Transaction PDSY is a universal way to access all this documentation, regardless of where it comes from. Via PDSY, you can view and edit documentation, using the same editor, for many different objects. Early releases of R/3 used report RPDSYS00 to view and maintain documentation, but it has been replaced with transaction PDSY. While RPDSYS00 may continue to exist, you cannot be assured it is showing you the most recent documentation. Document the ‘Why’

Each rule, schema, wage type, and constant can be documented online. Click on the Goto menu and select Documentation. From there, you can enter documentation on why you are making the changes, reference the transport it is assigned to, and perhaps enter other change management information (i.e. issue number, ticket number and so on). The critical part is to define why you are making the change, not just saying what the rule does. Most people who have to come behind you to modify the rule can see what the rule is doing, but may not know why it was done a certain way or if there are other dependencies in the schema. This sort of documentation requires

very little effort, and saves much time in the future.

Expanding the Schema and Rules

Report RPDASC00 can be used to pull all the COPY schemas and rules into one list. This is very useful when you are looking for certain things in the schema – for example, where is wage type 0COL used? Running the report as shown in Figure 10 lists all schemas, sub-schemas, rules, and sub-rules for the main schema ZUAT.

Figure 10 Report for main schema ZUAT

Running the Payroll Driver

The payroll driver can be run a number of different ways. From the payroll menu for a specific country, select the Payroll>Start payroll option. Or use transaction PC00_Mxx_CALC, where xx is the country identifier (or MOLGA). The payroll driver can also be executed from transactions SE38 and SA38. Any way you go, this selection screen comes up (using U.S. payroll and the test employee as an example). (See Figure 11.)

Figure 11 Payroll driver selection screen for the United States

If you are using the schema ZUA0 for production payroll, the payroll period is always left at Current period unless you are only running simulations, which tells the payroll driver to get the current pay period from the payroll control record. If you use the test schema ZUAT, you could select Other period and then enter whatever period and year you want to run, and save those results (only in a non-production system). The payroll area in this section is required and tells the payroll driver which payroll area to use for deriving the current period, the period begin and end dates, and other payroll area-related data.

The selection section specifies which groups of employees you include in the payroll run. The payroll area entered here determines which ones are included in the payroll run. These payroll areas need to have the same setup as the one entered at the top of the screen – the same period definition and pay dates, for example.

General program control is used to tell the payroll driver how to run the payroll. Off-cycle payroll uses various reason codes, and those codes can be entered here. If running an off-cycle payroll, you specify the type of payroll and the date of that payroll in the Off-cycle payroll line. The schema line specifies the main schema to use for the calculation. If you want to force a payroll run to go back to a certain date and recalculate everything since then, that date is entered in the Force retro.accounting as of field. And finally, there is an option for a test run – also known

as a simulation run.

Each payroll function and operation has the ability to put additional diagnostic information in the payroll log. For testing payroll, it is good to have the log shown. In a production payroll, showing the log for a whole payroll area will severely affect system performance. The log requires a lot of temporary storage and significant processing resources. If the Display log for time management additionally is selected, then you will be able to jump from the payroll log into the day processing (DAYPR function) part of the gross payroll schema UT00. Otherwise, that part of the log is not generated. Display variants can be created to customize the way the payroll log is displayed, and if one has been defined you can select it in the Display variant for log line.

Finally, the remuneration statement parameters are used to define which, if any, HR Form is displayed at the end of the payroll calculation. If a form is specified here and the log is not displayed, then the payroll driver displays the results via that HR Form. If the log is displayed, it first displays the log but also gives you a button at the top to display the HR Form.

Reading the Payroll Driver Log

The payroll log varies from one release to another and from one country to another. It can also vary from one customer to another depending on how the schemas were customized. For these examples, the payroll log follows the standard schema U000 very closely, on the Enterprise release. (See Figure 12.)

Figure 12 Payroll log in Enterprise

The log tells you that one employee was selected, and one em ployee was successfully calculated. The number of periods calculated may be more than the number of employees, since it counts the current and retrocalculated periods. Employees rejected from payroll would be counted in the Rejected line. The payroll driver rejects employees for two primary reasons – a lack of basic and consistent master data, and customization errors.

Each node can be opened to view deeper levels of processing, until you get down to a particular function and/or rule. To get to my example, you expand the nodes to the point shown in Figure 13.

Figure 13 Expand the nodes

For the PIT function and rule ZUA8, you can see the Input, Proce ssing, and Output sections. These sections vary by function and operation, but are vital to testing and tro ubleshooting. If you double-click the PIT function, the payroll driver displays the contents of the input, processing, and output sections together in one list. Or you can double-click any one section to see its contents alone. Likewise, you can further ex pand each section to see individual components – in this case, wage types.

In many of the detailed lists, you can see two icons – a green plus sign with a down arrow and a red minus sign with an up arrow (Figure 14). These icons control the level of detail that is displayed in the list. Click the green plus to see more detail and the red minus to see less.

Figure 14 Green and red icons control level of detail

Understanding Which Wage Types Are Processed

A rule can also filter wage types, or it can process all wage types. It can filter by employee-subgroup grouping and by wage type. This is an attribute of the rule, and different logic can be executed for each set of filtered wage types. In Figure 15, you tell the editor you want to edit the section of the rule that will process wage type 0BAS for all employee subgroup groupings. To see all the various wage types a rule is set up for, click the overview button once you are editing the rule. The various sections can be managed by the Edit>ES Grouping wage or time type menu path inside the rule. If the employee subgroup grouping or wage type are set to asterisks, then they are valid for all values.

Figure 15 Select the section of the rule that will process wage type 0BAS

The rule’s treatment of wage types is also affected by how it is called by the function. The rule gets its wage types from the function, so the function controls what the rule can process. Parameter 2 has the following values:?GEN –Only access the ‘****’ wage type section of the rule.

?Pxx –Like GEN but brings along the value of the processing class ‘xx’.

?Exx – Same as Pxx except for evaluation classes.

?(blank) – Access the section of the rule that corresponds to the current wage type

Parameter 3 can have two values:

?NOAB – Only access th e ‘*’ employee subgroup grouping section of the rule.

?(blank) – Access the rule specifically for each employee subgroup grouping

The employee subgroup grouping for personnel calculations rules is maintained via view v_503_b.

Example 1 – Calculating a COLA Wage Type

The first example multiplies wage type 0BAS by 0.15 and puts the result into wage type 0COL. Figure 16 shows

the IT before rule ZUA1.

Figure 16 IT before rule ZUA1

Figure 17 shows the processing section for rule ZUA1, showing calculation done on wage type 0BAS.

Figure 17 Processing section for rule ZUA1

See Figure 18 for the IT after rule ZUA1 was processed, showing the new wage type 0COL with the same A and AP splits as wage type 0BAS, and 0.15 in the NUM field to reflect the percentage used in calculation.

Figure 18 IT after processing of rule ZUA1

Example 2 - Restricting COLA to Specific Groups of Employees

Rule ZUA3 shows how to restrict COLA based on personnel area and employee subgroup. The calculation is the same – 15 percent of wage type 0BAS is put into wage type 0COL. The IT is the same as rule ZUA1, both before and after processing. The difference is in the processing section (Figure 19).

Figure 19 Processing section for rule ZUA3

If the employee is in personnel area ACAF, then you look at which employee subgroup they are in (OUTWP operation with the PERSB option). If they are in employee subgroup PS, then you calculate COLA.

For employees who are not in personnel area ACAF, or are in ACAF but not employee subgroup PS, y ou perform the ADDW T * operation. This copies wage type 0BAS from the header row to the IT. If you didn’t do this, that wage type would be dropped from the payroll calculation at this point.

Example 3 - Bracketed Calculations & Flat-Amount Override

The th ird example shows how to use the AMT operation to make decisions based on a wage type’s value. A nested decision structure is used calculate COLA with various rates. If wage type 0COL already has a value then you keep

that amount instead of doing the calculation. Since you ran out of room in the variable key in rule ZUA4, you break the logic into two rules, calling rule ZUA5 from ZUA4 when needed. The IT before processing is the same as in the previous examples, but the processing is significantly different (Figure 20).

Figure 20 Processing using AMT operation

Notice how the PIT function starts with rule ZUA4, branches to ZUA5 and then returns. When wage type 0COL is entered via infotype 2010, the rule’s behavior changes. The IT before processing now has 0COL in it (Figure 21).

Figure 21 IT with 0COL

The processing section now sees 0COL and simply passes it on to the outgoing IT table (Figure 22).

Figure 22 Outgoing IT table with 0COL

Notice that if wage type 0COL is entered for someone who is not in personnel area ACAF and employee subgroup PS, then it would be paid anyway. Rules ZUA4 and ZUA5 are processed only for wage type 0BAS. So if wage type 0COL existed in the IT before this rule, it would simply be passed on to the next function. This can be restricted by customizing views v_511_b, v_503_g and v_001p_k so that 0COL cannot be entered for this combination of personnel areas and employee subgroups.

Example 4

Hard-coding amounts and wage types into rule is a bad practice. Example 4 is the same calculation logic as Example 3, but the amounts are moved into constants, and use a processing class to specify the COLA wage base. Table t511k, or view v_t511k, holds payroll constants. These constants are date-effective, and are read with the end-date of the pay period being calculated.

First you set up the new processing class. For customer-defined processing classes, start with 99 and work down. For this case, use processing class 90. In the IMG, go to the section for processing and evaluation classes (Figure

23).

Figure 23 IMG section for processing and evaluation classes

Execute the Maintain processing cla sse s and their specifications item, and create processing class 90. Note that you can click on the blue "i" icon to document the processing class (Figure 24).

Figure 24 Click on the blue "i" icon to document the processing class

Select the processing class 90 row and then double-click on Proce ssing cla ss specifications. Here is where you define each value of processing class 90 (Figure 25). You can also document each value. Then go to view

v_512w_o to set wage type 0BAS processing class 90 equal to 1.

Figure 25 Set wage type 0BAS processing class 90 equal to 1

Now you create the constants in t511k (using transaction sm30 and view v_t511k). E ach constant can be documented (Figure 26).

Figure 26 Creating constants

Rule ZUA3 also changes since you now have to execute a rule for a specific processing class. Use the P90 value for parameter 1 (line 150). (See Figure 27.)

Figure 27 Use the P90 value for parameter 1 (line 150)

When payroll runs, the processing section for rules ZUA6 and ZUA7 look much the same as before, except you see constants and processing classes (Figure 28).

Figure 28 Processing section for rules ZUA6 and ZUA7 with constants and processing classes

Example 5

The last example involves the handling of wage type splits. Some of the splits have documentation, others don’t. When viewing the RT table with the pc_payresult transaction (or the Display Results option in the Tools menu in Payroll), select a split value with your cursor and then press F1 for help. This gives you the full name for the split indicator. Some documentation is also available in transaction PDSY, using operations ELIMI and SPLIT. See Table 2 for common split indicators.

相关主题