Implementing SAP ERP HCM globally either in a big-bang or country rollout implementation is a strategic effort with lots of different pieces. For example, from a technical perspective, there are many things to consider for solution architecture, data conversion strategies, and customizations.

The strategy you choose for activating countries within SAP ERP HCM has a drastic impact on the functionality and technical aspects of a project. One example is that most of the different countries in the SAP ERP HCM system have unique country-specific infotypes and screens. The result of this is that separate data conversion programs need to be leveraged along with different logic for pulling data based on country.

At the very beginning of any SAP ERP HCM project, project leadership and architects have to decide whether to activate the country-specific switches in the SAP system or if they are going to assign a country or countries to country-independent global settings (referred to as the MOLGA 99 solution). I cover the technical as well as strategic choices and challenges facing projects when undertaking a global SAP ERP HCM implementation.

Which to Choose: The Country-Specific or the Global MOLGA 99 Solution?

One of the most important decisions that must be made at the beginning of a project is whether to activate the country-specific functionality for each country in scope or if it is better to use the MOLGA 99 solution. Both options come with their own pros and cons and can affect the cost of a project. I discuss both options, and their plusses and minuses in different situations.

The Country-Specific Functionality Solution

In an SAP ERP HCM implementation project, activating the country-specific functionality for each country is called activating the country-specific MOLGAs. If a company is implementing payroll for the given country and is required to also run legal reporting out of the SAP ERP HCM system, the best solution is to activate the MOLGA for that country. This is because, for each supported country, the SAP system delivers a standard localization.

For example, if a country is implementing in Canada and is required to do legal Employment Equity Act (EEA) reporting out of SAP ERP HCM, you need to turn on the MOLGA for Canada. This is necessary because the SAP system delivers several country-specific configuration tables and programmatic codes for Canadian legal reporting. You must have the MOLGA activated to leverage the functionality. These reports require a lot of specific data elements that can be found on standard country-specific infotypes and tables, all of which are available when the switches are activated.

In addition to reporting and infotypes, activating MOLGAs also allows SAP ERP HCM users to deliver country-specific functionality, such as specific personnel actions and country-specific drop-down values where needed. Users are able to gain access to country-specific drop-down options and data values for given employees based on the employee’s country.

For example, you can use the personal ID infotype (infotype 0185) or other country-specific infotypes to store country-specific identification numbers for employees (e.g., the National Registration Identification Card [NRIC] for Thailand, the tax filing number for Australia [infotype 0227-TFN Australia], and the Powszechny Elektroniczny System Ewidencji Ludno?ci [PESEL] number for Poland [localized version of infotype 0002, personal data]) where needed. Regarding personnel actions, users can define country-specific personnel actions to appear based on the person affected by the transaction within the system. This is done by using the IGMOD feature (Figures 1 and 2). Feature IGMOD allows project teams to set country-specific configuration settings based on country.

Figure 1

Feature IGMOD in table T500L

Figure 2

Feature IGMOD showing specific configuration based upon MOLGA (country)

For example, when hiring a Belgium employee, a Belgium-specific hiring action appears and includes country-specific Belgium infotypes such as infotype 0100 (social insurance B) and infotype 0101 (fiscal data B).

Another example of where country-specific functionality can be activated in the SAP ERP HCM system is in the personnel and enterprise structures. Users can show specific values for employee group, employee subgroup, personnel area, and personnel subarea based on the country of the employee.

A good illustration of this is how companies define the enterprise structure (personnel area and subarea) based on each country (Figure 3). If the personnel area for a project is based on a geographic location (e.g., Paris, London, or New York), you could cleanly separate the different locations by country and ensure that your employees are tied to the country-specific personnel areas. If country-specific MOLGAs are not set up, all personnel areas would be permissioned to all countries (Figure 4). This would lead to issues such as employees being placed into invalid personnel area combinations (e.g., an employee is assigned to New York in the country of France).

Figure 3

Sample configuration table showing restricted personnel areas based on country (MOLGA)

Figure 4

Sample configuration table showing personnel areas with no country restrictions (MOLGA 99)

Figure 3 shows the configuration for table V_T500P in the SAP ERP HCM system. In this example, personnel areas 1000, 1100, 1200, 1300, and 1400 only appear for German employees, and personnel area 1900 only appears for employees being transacted on in Portugal. Figure 4 shows the configuration where all personnel areas are assigned to MOLGA 99 (other countries). These personnel areas are allowed for all countries.

One key requirement that commonly comes up in global SAP ERP HCM implementations is the ability to restrict certain employee groups and employee subgroups based on country. This is mainly to ensure that companies can restrict certain types of employees from being hired based on the country where the company is located. For example, Figure 5 illustrates the SAP ERP HCM system’s ability to restrict the combination of employee group 1 (regular employees) and employee subgroup A0 (applicant) to be allowed only in Germany. This enables employers to restrict the SAP ERP HCM system to hire applicants from only one country; in this example, Germany. This would not be possible if you use MOLGA 99.

Figure 5

Assignment of employee group or employee subgroup based on MOLGA (table V_T503Z)

One other key consideration for activating the different country-specific switches is that the SAP system offers a significant amount of localization (country-specific functionality) which is critical for payroll to run. As already mentioned, there are country-specific infotypes in the SAP ERP HCM system and legal reports that are country specific. There are also several global infotypes (e.g., infotype 0002 [personal data], infotype 0006 [address], and infotype 0077 [additional personal data]) that have country-specific fields when countries are activated. Figures 6 and 7 show examples of how Japan and Italy both share infotype 0002 (personal data), but have a country-specific view for each.

Figure 6

Infotype 0002 (personal data for Japan)

Figure 7

Infotype 0002 (personal data for Italy)

In Figure 6 the Japan Personal Data subscreen supports the ability to store names in local characters (e.g., Romaji, Katakana, and Kanji). In the Italian version (Figure 7), the Personal data subscreen does not have this option, but stores critical details such as an employee’s date of birth, birthplace, state, language, country of birth, and nationality. If a company needs to run payroll or legal reporting out of the SAP ERP HCM system for Italy and Japan, these screens must be used as key data related to the employees resides on these country-specific screens.

As you can see, there are several advantages to activating the country-specific switches in the SAP ERP HCM system. This option, however, can be more costly to implement as project teams need to do a lot of country-specific functionality configuration and development. In addition, activating each country requires project teams to have separate data conversion programs for many of the global infotypes (where country-specific fields exist like in the examples, above), as well as have conversion programs for each of the country-specific infotypes. This adds a lot of complexity to your SAP ERP HCM solution when it’s being built, and requires thorough testing to be conducted to ensure that all the country-specific functionality is working correctly.

The MOLGA 99 Functionality Solution

When project leaders decide to implement a simpler solution, and legal reporting and payroll are not in scope, using the MOLGA 99 solution may be the best option. When you use the MOLGA 99 solution each of the SAP ERP HCM personnel areas is assigned to a country grouping of 99 and no country-specific functionality is called. With this setting, users do not enable country-specific functionality such as legal reporting and country-specific payrolls. The major benefits of this solution are that it involves less configuration and it allows users to get employees into the SAP ERP HCM system quickly. In addition, data conversion is much simpler as country-specific screens are not used and the same conversion program can be used per infotype across all countries.

There are several distinct disadvantages related to the MOLGA 99 solution that project teams must clearly understand before making a decision. One of the most important is that legal reporting is severely limited as country-specific infotypes and logic are not leveraged. Most of the country-specific reports depend on the mapping of personnel area to company code and the appropriate and relevant country (MOLGA), as shown in Figure 3.

If countries are not assigned to the proper MOLGA, projects are not able to run standard country-specific legal reporting out of the SAP ERP HCM system without customization to make these reports work with the MOLGA 99 country (and other attributes to be defined by the project). In addition, projects are not able to easily have country-specific personnel actions. The main reason that this is more challenging is that projects aren’t able to use the MOLGA field to determine the country, as all countries are assigned to MOLGA 99. To achieve country-specific actions with the MOLGA 99 solution, custom configuration and hard coding of personnel area or personnel subareas has to be done to enable country-specific personnel actions.

See Table 1 for a side-by-side comparison of the two options — the country-specific MOLGA solution and the MOLGA 99 solution.

Table 1

Pros and cons of country-specific MOLGA and MOLGA 99 solutions

The Recommended Path for Activating MOLGAs 

It is standard practice for global SAP ERP HCM implementations to activate the country-specific MOLGAs per country. SAP delivers several global and local country-specific functionalities, which, in turn, depend on the country-specific MOLGAs being activated. Although this may take a bit longer to build, this is by far the best strategy as it helps ensure that your company has the latest functionality built within your SAP ERP HCM system to support local payroll and legal reporting.

One common business case for activating MOLGA 99 is in situations in which a company already using an SAP ERP HCM system acquires another company and requires fast integration to get the combined company under a single HR environment very quickly. One possible, easy solution is to create HR structure values for the employees from the newly acquired company and put them in the MOLGA 99 solution. However, as mentioned previously, these employees would not be part of the legal reporting and payroll until the full MOLGA solution is implemented, so this is just a temporary fix. These pros and cons should be considered fully, and communicated to the project leadership team so that they fully understand the functionality that will be in and out of scope based on the design decisions that are made. A list of pros and cons around this issue is shown in Table 1.

Finally, as stated in my previous SAPexperts article “Tips for Implementing Basic Management of Global Employees in SAP ERP HCM,” project teams also need to evaluate whether there is a need to activate the Management of Global Employment (MGE) module, a component of the SAP ERP HCM system. Based on requirements gathered, a project team may have specific needs to enable additional infotypes and personnel actions related to expatriates and the expatriate process. If MGE is necessary, you should follow the recommended path to enable country-specific MOLGAs as MGE is intended to integrate an employee’s multiple assignments across numerous countries. In addition, there is specific functionality and configuration that is MOLGA specific, such as enabling country-specific personnel actions and setting rules for multiple assignments across different countries to an employee. More details about this can be found in my above-mentioned article.

Mark S. Jackson

Mark Jackson has been working with SAP ERP HCM for more than 12 years and specializes in SuccessFactors Employee Central and the SAP ERP HCM Personnel Administration and Organizational Management modules. He has had numerous experiences with implementing and leading SAP ERP HCM and SuccessFactors globally and is a subject-matter expert in defining global templates for SAP/SuccessFactors implementations.

You may contact the author at Mark.S.Jackson@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.