Implementing SAP Payroll in Multiple Countries

OVERVIEW

You may think that various countries are very different in how they are paid and maintained. One of our customers studied their operations and found that 80% of their global payroll processes were the same – only 20% were unique to a specific country. By standardizing the configuration & coding among countries you achieve at least three significant benefits: simplify and reduce support costs, leverage your hardware investment, and have the opportunity to get a global view of your employee data

Even if your company may have only one country-payroll now, it is good to plan and configure as though you may add more in the future. In this increasingly global business environment, and given SAP’s global HR capabilities, it is not unlikely that you will have a new country payroll in the future. Setting up the system to enable that possibility is much easier to do before go-live than it is after.

There are dozens of items to pay attention to when approaching an SAP HR project with a global mindset. However, the are four general areas to pay attention to:

CODING SCHEMES

SAP HR has many areas where employees are grouped into categories so that they can be processed or report later on – employee groups & subgroups, payroll areas for example. ‘Actions’ are also used to enforce standard processes for maintaining employee data. Most of these items are not country-specific, so when you determine how to configure them, think about it on a global basis. A manager in the UK can probably be in the same employee subgroup code as managers in the US. The infotypes used in hiring someone in Germany are different than in the US, so use the same action type, but different actions reasons. By using common codes across countries you will be able to report on your HR data from a global perspective.

One exception to this is that even though payroll areas are not country-specific, it is preferable to use them as if they were country specific. The gross-to-net process is different from one country to the next, and since payroll area is used to select employees for calculating payroll, it’s best to align them by country.

CUSTOMIZATION

Some critical customizing objects are country independent – such as features and events/actions. Customization of these objects depends on how you setup your coding schema for employee data. Other objects, such as schemas and rules, have to be treated differently.

The main schema for Germany is D000 and for the US it is U000. Many people customize the schema, so their customized version usually gets a ‘Z’ in the first character. But we can only have one Z000 schema. The same applies for payroll rules – you may customize X011 or X013 or U013 – but by simply placing a ‘Z’ in the first character of the new rule name will create conflicts between country-specific payrolls. The best solution is to have a global standard for naming schemas and rules. A good standard is to start the schema/rule name with a Z, then use a one-character country identifier, and then the remaining two characters are a sequential counter (00 through ZZ). So a modified U000 becomes ZU01, and the modified D000 becomes ZD01.

REPORTING

When working with only one country in a system, there’s no need to worry about which country you are reporting. But when there are multiple countries it is a concern when you wish to report data for a specific country. For example, in a simple report on payroll results you would do a ‘get pernr’ on the logical database PNP, then import the cluster directory, loop through the results to find what you want, report it and move on to the next personnel number.

The problem here is that the country identifier is not a selection on the logical database PNP. The method mentioned above will return employees in multiple countries. Since most payroll reports are country specific, and there are multiple countries in the database, some extra thought needs to be done in reporting. Many people run payroll reports per payroll area, but in the US that gets awkward due to the different payroll period frequencies. If the number of personnel areas is small (rarely the case) then you can restrict the data selection by specifying those personnel areas in the selection screen. A simple automated solution is to see if the personnel area the employee belongs to is in the country you want to report on. This can be done in a few lines of ABAP code right after the ‘get pernr’ statement.

SUPPORT

HR Support Packages (HRSP’s) are released by SAP every few weeks to correct software bugs and implement new HR regulatory requirements. One of the side-effects of operating a global SAP HR environment is that HRSP’s will need to be implemented more often. For example, in the US the year-end HRSP often is released in November; but for European payrolls the year-end HRSP is released towards the end of December. Each country needs their respective HRSP, but having to apply two HRSP’s during the busiest time of the year (for HR/Payroll people) is burdensome.

A benefit of a global SAP HR/Payroll environment is that support for the common processes can be centralized. Most firms find cost savings when support can be centralized.