SAP Payroll Basics - Part 1 The area most often overlooked when training people on SAP Payroll is the

basic, fundamental meaning and usage of payroll schemas, rules, wagetypes and their associated processes. We will try to correct that. First, we will present an overview of the basic parts of the payroll process, then in subsequent articles well go into more detail on each one. Not every possibility will be covered that would be a multivolume hard-back series of books, not an easily read web-based article. But we will cover the basics in a way that gives you a good understanding of SAP schemas and rules from there you can use that knowledge base to learn as much as you want about the rest of this subject.

SCHEMAS AND FUNCTIONS

In SAP Payroll, functions provide the high-level logic for payroll calculations. Functions perform general processing such as calculating payroll taxes on a given set of wages, reading wagetypes from specific infotypes, calculating benefits premiums, and storing the results of the payroll calculation. There are dozens of functions in SAP payroll, some are country-specific and others are not. Each function is defined and documented via transaction PE04; you can also view the function documentation via transaction PDSY in releases 4.5 and greater, or with report RPDSYS00 in earlier versions.

In SAP HR terms, a payroll function is not the same as an ABAP function. A payroll function does consist of ABAP code, but it is not executed in the same way an ABAP function would be. Payroll functions are executed within a schema by the payroll driver program (lets assume RPCALCU0). A schema is just a collection of functions executed in a specific order each one passing its results on to the next. Schemas are always created and edited via transaction PE01, but are actually stored as a collection of rows in tables T52C0 (SAP standard schemas) and T52C1 (customer-created schemas and modified SAP-standard schemas). The payroll driver reads the lines in T52C0/T52C1 and executes the functions one by one. So how do we make the leap from a payroll function stored in a table to the execution of ABAP code to get the work done? In transaction PE04 you can see the ABAP code associated with every function. The function name in the schema correlates to an ABAP form for example payroll function WPBP maps to the ABAP form fuwpbp; function USTAX maps to form fuustax. So when the payroll driver is executing the schema, it takes the function name from the current row in schema, puts an fu on the beginning of the name, and then does a perform statement on it. Its a very simple and elegant design.

WAGETYPES In a broad sense, a wagetype simply holds a piece of data a rate, number, and/or amount. But more specifically, a wagetype has dozens of attributes that control how it is manipulated and processed. In the end though, it ends up as an object in the payroll results database that stores a rate, number, and/or amount. The most typical use of a wagetype is to store the amounts of earnings, deductions and taxes in an employees paycheck. A persons base pay is stored in a wagetype, the amount of their United Way deduction is stored in a wagetype, and their taxable wages & taxes are stored in wagetypes. Wagetypes, as the primary data element for employee paychecks, are also mapped to FI/CO accounts to record the debits and credits resulting from the paycheck and reported on the W-2 and other tax forms. Wagetypes can also be used to store statistical data such as the number of hours worked in a pay period, the average weekly wages for the past six months, or the amount of wages eligible for a profit sharing calculation. Wagetype attributes are stored in several tables, but the central table is T512W. Much more time will be spent on various aspects of T512W. There are three categories of wagetypes model, technical, and user. Model wagetypes are delivered by SAP for customers to use as guidelines for creating their own wagetypes. They always start with a letter and SAP may add, delete or update them in system upgrades or HRSPs. Technical wagetypes always start with the / symbol, and are delivered by SAP. They are intended for very specific standard processing in payroll, and while you can modify them, SAP may also update them during upgrades or HRSPs. So if you ever (I mean EVER) change a technical wagetype, check it after each upgrade or HRSP to make sure it still has the attributes you want. And never delete a technical wagetype. User wagetypes always start with a number and these are wagetypes that SAP does not change during upgrades & HRSPs. OK, SAP rarely changes them in upgrades and HRSPs. User wagetypes are for all the companyspecific payroll payments and deductions.

RULES AND OPERATIONS A long-time client of ours once created a screen-saver message that stated Payroll Rules!. Those of us who were experienced SAP Payroll analysts or consultants immediately saw the double meaning, and corny humor, in that message. Rules contain the most basic logic used in SAP Payroll. Where a schema is a collection of functions, a rule is a collection of operations. An operation is a very basic piece of logic that is used, mostly, to manipulate wagetypes. For example, operation MULTI multiplies the number and rate fields of a wagetype to determine the amount to pay an employee. Operation OUTWP retrieves specific data about an employee so that another operation can make a decision on how to process it. For example, if the work contract on infotype 1 is UA then do x, if it is UB then do y, otherwise do z. Operations can also be viewed in transactions PE04 and PDSY, and are edited with transaction PE02. Where a functions ABAP equivalent form starts with fu, an operations ABAP form starts with op. For example, operation MULTI would have an ABAP form opmulti. Rules, like schemas, are stored in a table rules are stored in T52C5. The more senior SAP consultants who have been working with computer systems for many years often find similarities between payroll rules and programming mainframe computers in Assembly language. While there is nothing fancy about operations, when used correctly together they can be very powerful. Hopefully weve presented a good but brief overview that makes sense. In our next SAP Payroll Technical Basics article we will get into more detail on the common functions used in SAPs payroll schema. Central Functions in the Payroll Schema Previously we presented an overview of the foundation of payroll processing - the basic structure of schemas, rules, function and operations. Now let's take a look at the major functions in the payroll schema. Functions can have up to four parameters, and usually the SAP documentation does a good job telling you what each parameter does. Documentation for functions and operations can be found via transactions PDSY or PE04. COPY This is the same as 'include' in ABAP and other programming languages. COPY just inserts the schema contained in parameter 1 when payroll is executed. Good programming style and good schema configuration style are basically the same - put commonly used logic in an 'include' so that it can be used in several places and to improve readability. BLOCK As of release 4.0 the schema log is organized in a collapsible tree structure. BLOCK BEG starts a node and BLOCK END ends the node. Everything between BEG and END is contained within the node. BLOCK BEG/END can be nested several levels deep. Again, place the BLOCK BEG/END functions appropriately to make the log easy to read. IF/ELSE/ENDIF

There are two ways to specify the true/false condition for an IF function. SAP has several built-in conditions that you can use in parameter 2 (IF NAMC in schema U000). You can also specify a custom rule in parameter 1, and in the rule perform whatever logic you want. In the rule you use operation SCOND to set the true/false switch for the IF function. Pxxxx The payroll driver & schema read and process data from many infotypes. The common way of doing this is with infotype-specific functions - named as 'P' and the four-digit infotype number. So, P0014 reads and processes data from infotype 14, P0168 processes life insurance plans from infotype 168 and P2010 reads in additional payments from infotype 2010. Many of these functions, but not all, allow you to futher refine the processing with a payroll rule. Schema UAP0, for example, shows that P0014 is processed futher by rule U011. Function P0168 is one of those that does not use a rule (in some older releases it does) - you specify options in parameter 1 instead (see schema UBE1). Some infotypes are used in payroll, but do not have a Pxxx function. Examples include infotypes 207, 208, 209 and 210 which are all read and processed in the main tax function USTAX. Infotypes 0, 1, 7, and 8 are processed by function WPBP. PIT PIT is an acronym for Process Input Table, and is one of the most used and most powerful functions in payroll. When wagetypes are read into payroll by the Pxxx functions, they are stored in an internal table called IT - Input Table. PIT loops through that table and applies logic contained in rules. So for each wagetype in the IT, it will apply the logic from a rule. The goal of PIT is to move wagetypes out of the IT and into the RT - Results Table. Most often, the rules called by PIT will change some attributes of the wagetype and then transfer it from the IT to the RT. The wagetype can also be left in the IT and even moved to other tables. We'll cover those possibilities when we reiew how operations work. A good example of PIT is in schema UAL0 - PIT X023. When the payroll driver gets to this point in the schema, PIT will look at each wagetype in the IT, and rule X023 tells it to do certain things depending on the wagetype's value in processing class 20. Values 3, 4, 5, 6, 9 and B will move the wagetype to the RT, while values 1, 7, and 8 leave it in the IT. Value 2 has no operation, essentially eliminating the wagetype from the IT. PRT PRT is short for Process Results Table. Although most wagetype processing happens via PIT, there are several occasions where you want to process the wagetypes that have already been transferred to the Results Table (RT). PRT work much the same as PIT, looping through the RT and applying logic from a rule. In schema UTX0, PRT is used to process tax wagetypes that are already in the RT. Function UTX0 (US tax function) returns its wagetypes directly to the RT, so any processing on tax wagetypes has to be done with a PRT function. ACTIO The ACTIO function processes a payroll rule, but it does not loop through a wagetype table. Instead it can loop over the different workplace/basic pay records and process the rule for each one. For example, suppose the employee had two infotype 1 records for the current pay period. ACTIO would have two records to loop through. Schema UTX0 again has a good example of ACTIO using rule UWH1 to calculate the number of working hours in the pay period.

Commonly Used Operations in SAP Payroll Previously we presented an overview of the foundation of payroll processing and information on the central functions in the payroll schema. So you know the structure of payroll processing and the major functions - now we will look at payroll operations, where most of the real work gets done. This subject area is very large and we are only scratching the surface here. Like functions, documentation for operations can be found via transactions PDSY or PE04. Operations can be placed in two broad groups - those that make decisions and those that manipulate wagetypes. Some of them fit into both groups. Manipulating Wagetypes Working with wagetypes in a rule is sort of like working with internal tables in ABAP. The function that called the rule (PIT, PRT, P0014 or whatever) loops through the table, placing each row, one at a time, in a 'header' space. You work with the wagetype in that header space, and when finished add it back to the table. MULTI, DIVID These operations let you multiply two fields of a wagetype and store it in a third. The fields you can work with are AMT, RTE and NUM. MULTI RNA would multiply the rate by the number and store the result in the amount field. DIVID ANA would divide the amount field by the number and store it back in the amount field. NUM, RTE and AMT These are very basic and powerful operations that manipulate the content of their respective fields. The F1 help documentation is very useful since there are so many ways to use these operations. On a basic level, you set values like NUM=1 or AMT=2.50 - though that it is bad practice to do this. Use constants instead - create a constant in T511K called ZNUM and then do NUM=KZNUM (set number field to the constant ZNUM). Since constants are date-effective and rules are not, this will give you more flexibility when the number has to change. You can set the field of the wagetype in the header equal to the corresponding field of another wagetype AMT=E9XXX sets the amount equal to the amount field of wagetype 9XXX in the RT. AMT< 9XXX sets the amount field to 9XXX in the IT only if it is less than what is already in the amount field (takes the minimum of the two values). Finally, you can use arithmetic on the values. RTE*100 multiplies the contents of the rate field by 100 and stores it back in the rate field. AMT*KZNUM multiplies the amount by whatever is in constant ZNUM. ADDWT So by now we've set the values of our wagetype using MULTI, DIVID, AMT, RTE and NUM. ADDWT transfers the wagetype in the header to some other table - enabling us to save all that work before the next wagetype goes to the header. The basic idea is that you transfer the wagetype to another table, with or without changing the wagetype number. ADDWTE* adds the wagetype to the RT without changing the wagetype number. ADDWTE9XXX transfers it to the RT and renames it to 9XXX. Again, the F1 help documentation will tell you all the tables that you can transfer to. ELIMI and RESET

Splits are attributes of wagetypes that link them to some other table in payroll. Sometimes you have to remove certain splits when doing work in a rule - that's what ELIMI does (ELIMInate splits). After you eliminate splits on a wagetype, within the same rule you can restore them with RESET. Generally you should avoid eliminating splits - it can lead to problems in pro-ration and reporting. So use with caution and test your work well. FILLF This simple operation resets the value of a wagetype field. For example, FILLF A resets the amount back to what it was when the rule was first called. So, here's how you would put these all together to calculate a deduction that is fixed percentage of base pay (there are several ways to do this, here's just one). Let's assume base pay is in the IT, the percentage is stored as a whole number in constant ZNUM, and you've made a rule that has a section for wagetype **** and for base pay, '0BAS' in this case. The deduction will be 4XXX. So in the schema we will do a PIT on rule Z001: PIT Z001. In the rule: Wagetype ****: ADDWT * (if it's not 0BAS we just want to pass it on without changing it) Wagetype 0BAS: ADDWT *, NUM=KZNUM, MULTI ANA, AMT/-100, ADDWT 4XXX (pass 0BAS on to the output table so we don't lose it, set the number field equal to constant ZNUM, multiply the number by the amount, divide the amount by -100 since we store the percentage as a whole number and we want deductions to be negative, and store the result as wagetype 4XXX) Making Decisions Many times we only want to take action if certain conditions exist - for example we only want to calculate deduction 4XXX for certain types of employees. For these cases, decision operations let us choose when to take that action. Decisions put their results into what is called the variable key - think of this like a case statement with wildcards. If I put the company code in the variable key, then the line that has 1234 will execute for company code 1234, 2*** will execute for any company that begins with 2, and **** will execute for companies that match neither. OUTWP This operation lets us make decisions based on various data elements in the WPBP table in payroll - roughly the infotype 0 and 1 data. There are many elements to look at, via the F1 help documentation. As an example, you could look at the company code via OUTWPCOMPY - this puts the contents of the company code field into the variable key. VAKEY Like OUTWP this places certain data in the variable key - see the F1 help documentation for all the possibilities. NUM, RTE and AMT Here they are again, as decisions. If I say AMT?0, it will compare the value in the amount field to zero and return either >, <, or =. Or you could compare it to a constant or another wagetype using the same concepts mentioned above. VWTCL

This operation returns the value of a certain processing class for the current wagetype. For example, VWTCL 93 places in the variable key the value of processing class 93. Rule X023 is a good example of how processing class values are used. In our previous example we calculated deduction 4XXX for every person who had base pay wagetype 0BAS. Using OUTWP you could decide to calculate it only for people in certain personnel areas/subareas, or for certain employee subgroups for example. Let's say that you only want to calculate it when someone has entered wagetype 4XXX in infotype 14 or 15. Assume here that the wagetype is entered in the infotype with something required in the number field. Here are the steps you could do: Wagetype 0BAS: ADDWT *, NUM= 4XXX, do a decision on NUM?0 and if = then do nothing, otherwise (the * condition) do NUM=KZNUM, MULTI ANA, AMT/-100, ADDWT 4XXX. Depending on how your wagetype splits are setup at this point, you might want to ELIMI R just before NUM=4XXX and RESET R before ADDWT 4XXX. As mentioned earlier, this is just a scratch on the surface. When configuring payroll you can not focus exclusively on just one piece of the puzzle - understanding how all the pieces are related will lead to the best configuration. There are many ways you can combine functions, operations, processing classes, and constants. SAP has created a powerful and flexible configuration model for payroll. When used correctly it gets a lot of work done well, but when done incorrectly it leads to confusion and instability. So test and document your configuration well! ORGANIZING SAP PAYROLL PROCESSING How many programs does your organization run to pay your employees? Depending on how many separate systems with which you interface, the list could be quite long. There are programs to drive the payroll, print the checks, create the bank file, post the payroll, send payments to vendors to name a few. With the introduction of SAP release 4.x came a new utility called process models which order and organize payroll processing. Visually, the process model is a flow chart of the programs in your payroll process. Process models can be created at least for regular payrolls, off-cycle payrolls, reversals, check replacements and bonus payments. The user initiates a process directly from the process model workbench or through the off-cycle workbench. Once the process is started, containers that carry necessary output from the previous program as selection criteria for the subsequent program. For instance, if running a regular payroll, the output container for the pre-DME program would be the payment run date and payment identification. This would also be the input container for the check-printing program. As the process is running, the user can see the status of each program by how many personnel numbers are processed and how many are incorrect. To prevent subsequent programs from running before the results of the previous program are checked, breakpoints can be sandwiched between the programs. Green lights indicate the process is finished and there were no errors. If a step does end in errors, they can be fixed and the step restarted

PROCESS MODELS

With a quick background behind us, what are the niceties of the process model? Obvious from the nature of the model, there is connectivity to the programs. Has your payroll processor ever gone down the list of steps to running the payroll and forgotten a step? With process models there will not be a list of to-dos since the programs are linked together in the model. The process model is a to-do list in itself. Also, there is increased automation with the process model. Because the programs are linked and the selection criteria are stored in variants and containers, the step of manually getting a variant and supplying the rest of the selection criteria is eliminated. This also eliminates possible errors in manually typing the selection criteria. Another time-saver is the availability of the status for each step. Throughout the processing, the status of the program can be checked for incorrect personnel numbers and errors. It is obvious if there is an error when the program is done running and there is an icon other than a green light for that program. With a right click on the step of the process, the user can go to the specific spool or job related to the program or the user can display the incorrect personnel numbers related to the program. The process model also allows parallel processing of appropriate steps. Since certain programs can be run simultaneously, the processing time will be reduced. Another key factor is processing history. If running programs without the workbench, the history of what is run can most closely be found through the job log and the spool list. Although this will contain what programs were run and their output, it is not organized with respect to the payroll process. The job log will contain any other unrelated programs that the user has run and wont group the programs by payroll area or process. There is only an alphabetical list of jobs run for the period of time specified. The process model will list each step in a process and its status. It is very conducive to determining where the payroll processor is in the process. If the processor has to unexpectedly leave for the day, her backup can go directly to the workbench and identify where she left off. Breakpoints were mentioned earlier. Part of the breakpoint functionality is notification. When the process reaches a breakpoint, specific people can be notified automatically. Perhaps after the programs for third party processing are finished, accounting should be notified to run the accounts payable payment run.

Having just focused specifically on the process model workbench, what is the big picture of payroll processing? Processes have to start somewhere. As mentioned previously, the beginning is different for payrolls for mass employees than for individual processing. Processes for mass payrolls are initiated within the workbench by creating a process that executes the steps in a process model. When the processor is ready to actually run the payroll, the process must be executed. Once executed, a selection program appears where the processor enters at least the payroll area and period. These are the initial selection criteria that get passed to the first program. The selection program will be different for different processes. A regular payroll process model will use H99_Select_Pernr whereas a special payment run model will use H99_Select_Pernr_Mass_Bonus. The latter allows additional payment types (special, correction, etc.) whereas the former only allows regular payroll runs. Individual off-cycle runs are actually launched in the off-cycle workbench. When a processor runs an off-cycle payment, reverses a payment or replaces a payment, the off-cycle information is stored in the table T52OCG. Then the

follow-up program RPUOCB00 (Subsequent Processes of Off-Cycle Activities) must be run to get processes started in the process model workbench. Off-cycle processing is organized by payroll area, period and payment type. So regular off-cycle runs will be grouped by payroll area and period. Special runs like correction and special checks will be organized by payment type and date. Replacement runs will be organized by payment run date and identification. After the follow-up program is run, the off-cycle processes will automatically start in the process model workbench.

CUSTOMIZING PROCESS MODELS FOR YOUR ORGANIZATION With the big picture in mind, how do you incorporate the off-cycle workbench, subsequent processing and the process model workbench into your payroll processing? There are two key components to recognize: how the existing processing can be restructured and improved and how the process models can be created to meet and exceed the needs of the payroll department. Here are some key questions to ask yourself and your payroll department. Think of the answers to these questions within the framework of improving your processing and incorporating the payroll tools SAP delivers. How many persons are available and needed for processing payroll in the department? Which payroll employees talents and abilities are best suited for the different roles in processing the payroll? In other words, what are your resources? Where does the process begin and end? For instance, are time and master data entered in distributed centers? Is the main portion of the payroll processed centrally? Are the checks printed in different locations? Are the distributed centers staffed deeply enough that someone can run the off-cycle payrolls related to their employees? Perhaps the distributed centers could run the off-cycles and the main payroll could run the batch process in the process model. How often do the checks and advices need to be processed? Twice a day, once a day? Most likely, the less times the batches of results have to be processed, the more efficient the processing. What processing records are kept currently? Is there a log of payrolls processed and can it be revised to keep less detail? If a processing log is kept, it could be reorganized to model the steps in your processes. Which programs can be included in the process model? SAP has designated many programs that can be used in process models some lesser-used ones may not be available for the process model. Perhaps the benefit of having other programs in a model outweighs the work to maintain a customer version of the programs. How many processes are needed? At a minimum, a different process will be needed for regular mass payrolls, offcycle payrolls and replacement checks. Models can also be created for mass bonus payments and voids if needed. Where should breakpoints be placed? The most obvious place for breakpoints is to stop the process before production runs occur so that the results of the simulation can be reviewed. Are there other strategic places where breakpoints can be used? On the other hand, is it necessary to have as many breakpoints as originally envisioned? Who should be notified at the occurrence of breakpoints? How are you going to set up each of the variants for the process models? One possible scenario is to start the name of the variant with the name of the model.

What else can you ask yourself and the members of your department which will lead to better organization? The needs of each payroll department will differ according to its environment. Spending some time pondering the answers to these questions may allow you to incorporate the payroll processing tools in your processing and improve the efficiency of the process. Of course, there isnt one ideal plan the fits the needs of all payroll organizations.

AVOIDING PROBLEMS Although the process models can bring organization and efficiency, there are some avoidable problems that may occur. SAP delivers standard examples of process models that can be copied and modified to suit your payrolls needs. Be careful to copy the SAP delivered model for the correct process. Each model is connected to a selection program and is assigned to a type of process (e.g. regular or off-cycle). Double-check the attributes of the model to ensure it is assigned to the correct selection program and model type. If either of these is incorrect, the process most likely will not start. As more processes are started in the workbench, the time it takes to refresh the list increases. Once processes are finished and correct, they can be at least closed. A filter can be applied to limit the number of processes viewed in the workbench and reduce the refresh time. For some, the process model workbench can be visually deterring especially if the model contains many steps. Be sure to number the steps to be visually logical within the workbench. Also, use descriptive text to explain each step. If you need to download or print the spool in a certain step, include that in the text for the step. Perhaps a step is Execute Posting. The text could be changed to Execute Posting (D) to indicate that the file should be downloaded. As mentioned previously, the names of the variants must be customized and transported. With some careful thought, the variant names can be created to avoid having to create transports at the last minute. For instance, it may be more useful to have a separate variant name for each combination of program and model rather than the same variant for the same program across several models. Then if you have to change the selection criteria for a program related to two different process models, you have the complexity to be able to change the selection criteria for the program related to a specific model. If the variant name were the same for both models, the change to the variant would affect both models. The process model workbench uses elements of the SAP Workflow module. If you create and execute a process and it never starts, check whether the generic workflow user is unlocked. Lastly, if there is more than one payroll processor, thought must be given to the security for viewing jobs and spools. If one person starts the process and another ends it, it will be necessary for the second person to be able to view the jobs and spools of the previous person.

Upon review of your payroll organization, the payroll tools can probably add efficiency and more order to the processing of your payroll. Rather than simply connecting the existing programs together in a process, use the tools to discover ways to help your organization.

Payroll Tax Models in SAP HR Tax models drive how wages are taxed in the SAP US payroll calculation. SAP supplies a general tax model with the system, but if you do business in local tax authorities or have complex taxation rules then you will most likely have to configure your own tax models. There are several steps and basic settings that define what is taxable, non-taxable, or adds to a taxable wage base. Several items on the tax jurisdiction (i.e. tax authority) have to be set up and then that is matched to the appropriate processing class values to achieve proper taxation. The first step is the most basic - identify each tax authority and give it a number. This number is the Tax Authority Model found in table T5UTE. In short, the Tax Authority Model is a jurisdiction, or group of jurisdictions, that has one set of taxation rules. To configure the tax models correctly you have to set up each authority that has a unique set of taxes. States such as California and New Jersey would have to have their own, but states that only have a withholding tax and have the same taxable wage base could be grouped together. However, for ease of configuration and to facilitate possible future changes, we advise you create a Tax Authority Model for every state. Since there are so many local tax authorities, grouping those by the state they are in and on taxation rules is the best option. Even grouping like authorities can lead to many different Tax Authority Models.

The next step is to set up various Tax Type Combinations, found in table T5UTY. This is a grouping of the different types of taxes into sets that would be applicable to an authority and applicable processing class 71 value. The same combination can be used with many authorities and many processing classes, as long as it matches the taxation rules. In many cases, most states would just have a tax type of 01(withholding). But some states or locals may have a 01(withholding) and a type of 53(school tax). To get those taxes to apply to one authority, you create a combination that has both tax types linked to it. An example could be tax combo 01 only has tax type 01(withholding) attached to it, but tax combo 02 has tax types 01 and 53(school tax) attached. Combinations should also take into consideration whether they are going to be applied to a residence tax area, work tax area, and/or unemployment tax area. This should be evaluated based on whether the tax type is driven by residence or work location. Occupational taxes are generally determined based on your work location. When the tax type combos have been created, you can then attach those to the tax models you created in the first step (table T5UTM). You have to attach these based on what you need for the work tax authority, residence tax authority, and unemployment tax authority. If a tax combo is not valid for a work tax area, but is valid for a residence tax area, then you would only attach that combo to that authority for the residence tax area. When attaching the tax authorities, you also need to specify what processing class 71value you want to tie to that combination. For example, you would want to create a PC71 value for a wage type that is to be added to a withholding tax wage base and not to be taxed. That PC71 value would have a tax combo tied to an authority that said tax type 01 with a value T (taxable base-no tax). Example Say you had three processing classes, x, y, and z. For processing class 71, x was fully taxable, y had earnings that should go to a wage base only for work and residence, and z was non-taxable for residence, but taxable for work. Below is a chart of a state and some tax type combinations set up for it. State R,W,U Combo Tax Types Taxability Indicator OK R 1 1 (withholding) Y (taxable) OK W 1 1 (withholding) Y (taxable) OK U 2 10 (UI) Y (taxable) OK R 3 1 (withholding) T (tax base) OK W 3 1 (withholding) T (tax base)

For processing class X you would use R and W with combo 1. For processing class y, you would use R and W with combo 3. If you want a wage to be taxable based on residence status, then you would only set up an R with a combo of 1. If you set up a combo with a tax type in it for a specific processing class, then the wage types with that processing class will have the taxes specified in the tax type combo taken out. If you don't want those taxes taken or applied to wage bases, then you do not link anything to that processing class. If you just want the wage type to add to a tax base, then you have to link the processing class to the correct combo that would utilize the taxability indicator of a T. Now, when payroll runs on an employee, here are the simplified steps it goes through to determine how to tax various items in the paycheck: Read infotypes 207, 208 and 209 to see what tax authorities the employee is subject to Read infotype 210 and 234 to get additional details for withholding taxes Read infotype 235 to see if the employee is exempt for other types of taxes For each wagetype (in the RT) and tax authority (T5UTE), use processing class 71 to lookup the tax type combo (T5UTM) - do this three times, for residence, work and unemployment. Find out what tax types are setup for each tax type combo and then use that to build the taxable wages per authority and tax type - now we have a matrix of wages by authority and tax type Send all this data to BSI, where the actual tax calculation happens Payroll tax is one of the most complex areas of any payroll system. This is just the tip of the iceberg of how it is done in SAP's Payroll module!

Year-End Processing in SAP There are a number of activities that must be performed at year-end for any payroll system. Our Year-End QuickStart Guide is intended to get you started on a successful year-end process. Some of the items may not be applicable for your firm, and we could go into much more detail for each item. There are some more common sense items not listed - such as establishing your year-end team and making sure your payroll is balanced. Be sure to visit SAP's Year-End web page for the latest information on year-end processing in SAP Payroll (use your OSS ID and password to access their page). The content on SAP's year-end site changes often, so visit it at least weekly. Also be sure to participate in SAP's Year-End Angel program - you can use Insight for your Year-End Angel just by notifying SAP and signing-up at our Year-End page.

Inform related departments about your year-end payroll and tax filing schedule (I.e. mailroom, printing services, etc) Make sure your SAP payroll calendar and related items are extended correctly into 2001. Verify employee social security numbers, names and addresses. Update Federal & State tax levies for changes in standard deductions. Review uncollected taxes (/Nxx wagetypes) and take required steps, if desired, to resolve them. Order tax forms and envelopes; make sure W-2 instructions are up to date. If you have customized Tax Reporter tax forms, tax form groups, or user exits, reapply those changes to the most recent SAP-delivered objects. Make sure SAP configuration is updated for 2001 state & Federal wage bases (I.e. unemployment, disability, etc) Review 3rd party Sick Payments and determine how you will enter them into SAP for W-2 reporting. Review W-4 exemptions and W-5's. Review reconciliations between GL and Payroll to make sure tax accounts are in balance. Make sure users are trained on Infotype 221/Payroll Adjustments processing. Make sure you keep current on BSI TUBS that have wage or rate changes for the upcoming year.

Using SAP HR Tax Reporter Every payroll or tax professional knows tax year-end can generate a large amount of stress during an already busy time of year. It seems several months can be devoted toward preparing for, living through and cleaning up after tax filing. Correct and efficient tax preparation eases the pressure of the tax season and leaves yourself, your employees and the government happy people. There are several things that can be done to ease the burden. Besides monitoring your employees tax data early, creating year-end checklists and attending year-end seminars, the SAP Tax Reporter functionality is advantageous in tax preparation during and at the end of the tax year. Before taking a look at the year-end W-2 forms and magnetic media reminisce on a plausible situation. Suppose an employee was exempted from Social Security and Medicare in 1999 and should have been subject to the taxes. Fortunately, you were able to collect the tax from the employee. Now, it is necessary to complete a W-2c, 941c, 941 and Schedule B with the revisions. There is a tremendous amount of manual work in calculating and completing these forms. Cautiously, you ask at least two other people double-check your forms because it is even more tedious to correct a correction. The savvy tax professional will download the fill-in forms from the Internal Revenue Services website to avoid the antiquated typewriter. Even with tremendous care, there is opportunity for mistake in calculation or completion. Is there a way to eliminate some of this overhead? This is one area where Tax Reporter can help. The idea behind Tax Reporter is to report on all the tax information stored in payroll clusters and third-party remittance tables so that it is readily available for tax reporting and filing. By reporting directly from the payroll tax clusters and remittance tables, some intermediate steps have been eliminated. The payroll or tax professional no longer needs to calculate or complete the forms. Because the data is readily available, forms can be produced on demand in test or productive form. Once run as a productive version, the form can be reprinted. If Tax Reporter had been run in 1999, the employee from the previous paragraph whose payroll results could be corrected will appear during a correction run. The W-2c and all other forms affected by the correction then can be printed. Eliminating another step in totaling the deposits made to each government agency can reduce the chance for error. Your organization may track deposits in a spreadsheet, refer to the general ledger or vendor account or some other method in order to report the payments made during the tax period. Fewer calculations provide less opportunity for mistake. Also, if drawing deposit information from payments out of a general ledger or vendor account, it is necessary to pull the correct information. There may be incorrect entries in the account, or deposits may not be the only transaction types in the account. Tax Reporter draws on the actual remittance data for each tax authority, eliminating yet another tedious step in the preparation before the form is due. If you have enough employees to warrant using SAP Payroll, chances are you are not aware of every adjustment to employees earnings each payroll. Perhaps you have distributed data entry areas and there was a change to an employees data that affected a previous tax year. How do you know this change took place? Because the prior years form and tax data is stored in payroll clusters, Tax Reporter can be periodically run to indicate any corrections. Even if Infotype 3 or the payroll control record is used to prevent retroactivity, there are cases when you need to allow an employees payroll to be calculated retroactively into the old calendar year. Tax Reporter can be used to see if there was a change to the employees tax data.

Again, with enough employees it may be difficult or tedious to track all changes to an employees W-2 information. Suppose an employee who received a 1998 W-2c requests a copy of his 1998 W-2 in 2000. A reprint of both the original and correction form can be created in the same place rather than having to copy paper or forms on microfiche.

PAYROLL-TAX REPORTER RECONCILIATION Although calculation and production of the forms is very straightforward, reconciliation is still a key part to successful tax preparation. Because SAP is so complex, incorrect data entry can result in incorrect results. In addition, special circumstances will have to be handled in conjunction with the use of Tax Reporter. For instance, how does your organize handle uncollected Social Security and Medicare taxes? Also, any current year claims that have been repaid should be handled using non-authorized manual checks where the taxable gross has not been reduced due to insufficient good money. The payroll reconciliation report queries payroll results and can show the differences between the payroll results and the results in Tax Reporter. It can also help identify special tax situations. For instance, SAP recommends that the payroll reconciliation report be run to show the current claims and then the claims report be run to show the detail to the claims. In addition, the payroll reconciliation report can be run to show unique situations like employees with /Ixx wage types or uncollected Social Security and Medicare taxes. Then these situations should be cleared up before yearend. Also, because forms like the 941 only report in total per quarter, the payroll reconciliation report can be run on the wage types used in the 941 to reconcile at the personnel number level. With this individual persons can be identified. Keep in mind that the payroll reconciliation report should be used rather than the wage type statement or tax type statement because it is more conducive to tax reporting. For instance, if the wage type statement were run on /701, it would report the taxable wages for all income tax levels (i.e. Federal, state and local). The payroll reconciliation report allows tax specific selection criteria and can be run over a range of time rather than only a single period. Necessarily, Tax Reporter is complex and requires some configuration and user training. Because government forms and regulations may change from year to year, planning ahead is a key to integrating Tax Reporter into the W-2 season. Preparing Tax Reporter does not have to be a lonely job though. Year-end support is available from SAP or other organizations depending on the need. In addition to the HR support packages (formerly legal change patches), which update tables and processing based on legal requirements, SAP offers support and an opportunity for feedback. It provides year-end configuration training and the Year-End Angel program. Consulting firms such as Insight can also provide configuration training and support specifically geared toward year-end. After the W-2 season has ended but is still fresh in everyones memories, SAP hosts year-end focus groups to draw on its customers suggestions and needs. Many changes to Tax Reporter have resulted from the focus groups. Some developments that resulted from last years focus groups include enhancements to the Tax Reporter log and the configuration checker. The log will show differences from the original results and the payroll reconciliation report can be used to identify the changes. The configuration checker is intended to isolate common configuration errors before the tax reports are produced. The days are gone sitting at a typewriter endless hours or individually preparing forms. Tax Reporter allows extra efficiency and accuracy in the calculation and production of forms. It provides a way to find tax data corrections. It also provides a complete package linking payroll data and tax forms. There is support available and prevailing requests for enhancements make their way to the end user. What more could the payroll professional need, except of course a real vacation during the W-2 season?

http://www.insightcp.com/research.htm

Copyright 2005 Insight Consulting Partners