Workers Compensation Report is a US Payroll Report very frequently asked for by several customers. This report is generated using the T-Code S_AHR_61016148 in SAP.

Here are the steps on how to create and relate the Workers Compensation Codes to SAP Jobs. One can go to SM30 and configure the below tables as explained to meet the business/legal requirement.

Table T513 – Create Job
Table T527X – Create Organizational Unit
Table T5UWC – Create Workers’ Comp Code (and text) in each state
Table T5UWS – Relate each Workers’ Comp assessable Wage Type to each State
Table T5U25 – Relate each SAP Job to Workers’ Comp Code
Table T5U26 – Relate Org Unit to Workers’ Comp State & Workers’ Comp Code

Below is a little more detailed explanation I have extracted from an SDN post (Thanks to Howard G):

Table T513
This table is used to establish new jobs. This table will need to be updated for any new SAP Jobs created before Table T5U25 (which relates SAP Jobs to Workers’ Comp Codes) can be updated. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Organizational Assignment => Organizational Plan => Define jobs

Table T527X
This table is used to establish new organizational units. It may not be critical to populate this table because org unit is the default method of workers’ comp reporting. If an SAP job isn’t related to a workers’ comp code, the system will attempt to use the org unit information to determine the proper workers’ comp code to use. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Organizational Assignment => Organizational Plan => Define organizational units

Table T5UWC
This table is used to create the workers’ comp codes in use in each individual state. You may determine that you’ll use a limited number of the standard workers’ comp codes and will update the codes in use infrequently. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Workers’ Compensation => Define workers’ compensation classification codes

Table T5UWS
This table is used to create the wage types that comprise workers’ comp wages in each state. Note that this means when a new wage type is created, a decision will need to be made concerning whether or not it is assessable for workers’ comp insurance. If it is not assessable, this table will not need to be updated. If a new wage type is assessable for workers’ comp insurance, the table will have to be updated. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Workers’ Compensation => Define state workers’ compensation wage types

Table T5U25
This table is used to assign each SAP job in each state to the workers’ comp code in that state. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Workers’ Compensation => Assign Workers’ Compensation codes to organizational structures.

Table T5U26
This table is used to assign each organizational unit to a default workers’ comp code and state. It is not critical to populate this table with all new org units, as it is used as a default when the system cannot find a relationship between a particular SAP job and a workers’ comp code. The navigation path through the IMG is: Personnel Management => Personnel Administration => Organizational Data => Workers’ Compensation => Assign Workers’ Compensation codes to organizational structures.

• Processing class 71 (Wage type tax classification) defines the tax combination that needs to be done. Table : V_512W_D
•  Each wage type is assigned to a taxability class via processing class 71.
• The tax classes are assigned to each tax model in different combinations in table T5UTM (Tax Model) and those values indicates for which wage types the tax type combination will be used.
• For example, if a wage type contains value ‘1′ (regular wages) in Wage type tax classification 71 and only tax models (assigned for each tax authority) which have a ‘1′ in the tax class field (defined in tax tables) will apply to the wage type and hence only those wages will be taxed using the specified combination.
• To quote one more example, say a wage type should not be taxed for a particular state but for other states it should be taxed. In this scenario, a new specification class can be created and assigned to the processing class 71 against respective wage type. The same value should be entered in the tax class field against all the tax models for which the tax has to be calculated and it should not be assigned to the model where it should not be taxed.

Table: V_T511 (Wage Type Characteristics)

Basically the table Wage type characteristics is used to define how the wage type has to behave in the payroll.  When the wage type is defined to accept the amount, we can configure it to accept zero value.

Configuration:

Ø  Input combination box would be present in the screen when the table is opened.

Ø  Under which the amount column should be defined with “.”  to accept Zero value and the number/ unit column should be “-”

Gross-Up wage types are created in order to make available  the whole net amount to the employee and the taxes will be borne by the employer. 

·         The concept behind the gross up functionality is that the net amount will be entered on the infotype and when payroll runs it takes the net amount and grosses up the taxes and adds that to the net to get a gross amount (taxes + net). 

·         Three wage types are needed to perform this:

1.       Wage Type Gross-Up – Net amount available to the employee

2.       Wage Type Tax Gross – Up – Tax Amount

3.       Wage Type Gross -Up Result  – Total Gross income 

·         Wage type Tax Gross-Up Results and Wage Type Tax Gross-Up needs to be assigned as 1^st derived wage type and 2^nd derived wage type against the Wage Type Gross-Up in the table V_ 512W_B (Valuation Bases).

 

 Note*: Wage type creation procedures are same like normal wage types.

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

 

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 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 the header row. After you are done with wage type 2100, wage type 4200 is moved into the header row.

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 http://help.sap.com. Click on SAP R/3 and R/3 Enterprise and then select your release level and language. Then navigate to the Human Resources>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.