The SAP time evaluation module is almost the only product on the market that allows you to configure complex business rules without programming. However, the price for this is increased complexity of time evaluation. I discuss some tips and tricks about configuring the rules using the sectioning functionality. It is necessary to know how to navigate between sections (i.e., how the work flow of time evaluation schema execution calls different sections in the right order) and how to organize personnel calculation rules (PCRs) using these sections.  

At the same time, SAP time evaluation addresses all possible time-processing scenarios, such as contract and bargaining agreement requirements (e.g., positive and exceptional time recording, overtime, holidays, premium and shift differentials calculations, absences processing, and time quotas). Time evaluation is also fully integrated with payroll and other SAP components (for example, personnel development, administration, training and events, payroll, benefits, and Cross-Application Time Sheets [CATS]). It supports retroactive calculations and changes. If you are not familiar with the basics of time evaluation, see the sidebar, “SAP’s Time Evaluation Module.”

Tips for Identifying and Resolving Time Evaluation Issues

Business rules are sometimes inconsistent from a business perspective. Therefore, it is necessary to consider some of the following issues that can interfere with the integration and flexibility of the SAP time evaluation module:  

• Too many variations in business rules. For example, in some cases the bargaining unit agreement does not cover all possible scenarios for processing employees’ time (i.e., daily and weekly overtime, holidays, or call backs) and there could be contradictions between applied business practices and legal requirements.
• SAP delivers only template solutions and guidelines, because it would be impossible to cover all possible business requirements. As a result, many processes can be configured from scratch, sometimes causing errors and inconsistencies.
• Configuration processes are not straightforward, and solutions are sometimes too integrated if requirements are too complex or inconsistent. For example, very often regular hours are counted towards benefits balances eligibility. However, regular hours may be converted into overtime hours (that are not counted) during time evaluation. Sometimes it is necessary to recalculate the whole payroll period for overtime calculations based on the total number of hours an employee works during the payroll period. In this case the countable benefits balance for the same day may be different when you review the results before or after recalculation.

• Incorrect time evaluation configuration may negatively affect payroll results. Time evaluation is the only SAP ERP HCM module that interacts with employees directly through the time recording system, thus bringing changes into the data. SAP time evaluation then processes the data for payroll, which means that the way time evaluation is configured can directly affect wages. It is easier to avoid making the wrong configuration decisions in the beginning, during the design phase, then to make changes in the working system later, during the configuration and support phases.

Tips for Time Evaluation Configuration

To ensure that your configuration is efficient and easy to maintain, keep in mind the following:

1. The structural approach to time evaluation, including:

• A site-centric configuration approach (where employee selection is clearly separated from the functional configuration areas). Employee selection in this context includes different rules related to processing time, such as different payment methods for different employees (salaried vs. hourly), eligibility for different payments (e.g., only some employees are eligible for night-shift premiums), and different rules for benefits such as vacation, personal days off, holidays (paid or unpaid), rate of payment, or unpaid sick time.
• The modular principle (where the same configuration module can be used in different parts of a configuration)
• Table-focused employee selection rules (instead of configuration in time evaluation schemas [TE schemas] and PCRs)

2. The answers to general configuration questions that are necessary to be used for global implementation, such as:

• Country-specific time evaluation solutions

• Multi-sectional personnel calculation rules (as building blocks for effective configuration and maintenance)

The Structural Time Evaluation Approach: Site-Centric Configuration and the Modular Principle

In the previous section two approaches to time evaluation are mentioned. First, let’s discuss the structural time evaluation approach in more detail.

When, from a functional perspective, the configuration for each site is not correlated with the configuration of another site, I call this the site-centric configuration approach. “Site” is a broad term and can mean any specified configuration area; for example, different countries, different companies (as defined in SAP object terms), different locations (e.g., state or province), different contracts or bargaining unit agreements, or any other specific configuration area that has predetermined configuration requirements.

I define the site-centric (or site-specific) approach as a separation of business processes related to different sites that allow configuration of each site independently.

With this approach it is possible to:

1. Achieve independent configuration for each site. Very often changes in bargaining unit agreements, contracts, or legislation are related only to specific sites and occur at different times.
2. Separate employee selection rules from functional blocks. In traditional SAP time evaluation configuration, employee selections and functional blocks are mixed but other employee selection and processing functionalities are in the same block. The problem is that employee selection business rules are being changed much more often than the functional processing business requirements. In the traditional approach the changes are done in one combined block. However, this potentially causes errors (due to complexity of this one block) and requires additional testing, which is often time-consuming and expensive if there is a change in functionality of the block. If you separate the employee selection rule and the functional blocks and later change the selection rule, it is necessary to test the applicability of the new selection rule to the updated employee population, while the functionality remains the same in the functional blocks. Also, when employee selection blocks and functional blocks are separate, each of them is smaller and it is easier to configure and track changes.
3. Achieve parallel configuration when different sites may be configured by different business analysts, and there is no cross impact of errors or inconsistencies between the parts of the configuration that should apply to a specific site.
4. Test only the necessary sites (i.e., where changes are done)
5. Merge or separate different parts of TE schemas relatively easily
6. Maintain and support each functional section independently (for example, site business analysts can concentrate on site-specific business rules and regulations)
7. Achieve extra benefits, such as shortening the TE schema execution time because the schema is executed faster as there is only one employee selection rule for each employee

The SAP system’s delivered time evaluation solution (e.g., TE schema TM04 [time evaluation schema without clock time]) — the most widely used SAP pre-delivered solution — contains several functional building blocks that are processed in the necessary sequence (Figure 1).

Figure 1

Time evaluation data flow

Sections related to subject areas (e.g., overtime, holiday, premium, and quota processing) are called processing sections. A processing section generally consists of employee selection rules (where a specific employees’ selection is defined for a specific functionality based on employee type, department, country, position, or other selection criteria) and a functional block (where different business rules for different employees are located).

If business rules are different for different contracts, locations, or bargaining unit agreements, then each processing section is required to have its own employee selection rule and its own functional block. In this case, the TE schema structure is similar to the one shown in Figure 2.

Figure 2

Typical TE schema structure

For example, if hourly employees are eligible for daily and weekly overtime then there is a type of employee conditional check (hourly/non-hourly). Daily and weekly processing section blocks are configured and included in the TE schemas only for this specific type of employee.

A Time Evaluation Time-Saving Tip

An employee’s selection rule is a configuration block that defines the selection of employees based on their organizational assignment (in SAP terms, personnel area/personnel subarea [PSA] groupings, employee group/employee subgroup groupings, company code, employee status, and other parameters that differentiate one group of employees from another to process specific business rules).

Therefore, changes in Organizational Management and in personnel administration configuration should be reflected in the employee selection rules for each processing time evaluation section.

Tracking each section is a tedious exercise that requires a full-time evaluation re-configuration and configuration analysis. Such changes then require a lot of testing. However, if the TE schema is structured as illustrated in Figure 3, then configuration changes in employee selection rules can be provided only once for each functional section. Changes in the organizational structure or in the contract require only one change in the schema in the one place that requires testing of the specific configuration object.

Figure 3

Site-centric configuration approach

The Structural Time Evaluation Approach: The Table-Centric Employee Selection Rule

The table-centric employee selection rule approach is a good alternative to making the configuration directly in PCR, where you would need to hard code the employee selection. It makes the configuration much more understandable. The essence of the approach is to configure the employee selection group in the configuration tables exactly as it is done for other configuration objects (e.g., work schedules, absences/attendances, and quotas) and check the grouping values of the objects in the TE schema to make a decision.

From a configuration perspective, the employee selection rule is a decision-making module that returns “true” if specific conditions are met and “false” if they are not. For example, if a specific functional module should be executed for the particular subset of bargaining units, then the employees’ selection rule module returns “true” when the employee belongs to a specific combination of personnel area/PSA groupings that generally define bargaining unit business rules.

Technically, such a selection (PSA grouping) may be done in PCRs — specifically by putting personnel area and PSA values in the variable key (Figure 4).

Figure 4

Variable key (eight characters are insufficient for personnel area/PSA groupings)

In PCRs, eight characters in the variable key for selection are not sufficient as major configuration objects for PSA grouping together require at least nine characters. The PCRs become unreadable and require deep analysis for each and every change. It is also possible to make a mistake either by putting the same configuration objects twice into different PCRs or to omit putting them into PCRs altogether.

The SAP system does not check for the existence of master data elements that are used in PCRs, and PCRs may contain references to non-existing or obsolete objects. Changes in PCRs require unit, integration, and regression testing of the whole TE schema.

Figure 5 illustrates how to use SAP standard table T001P as the employee selection rule in a TE schema. Table T001P is used for PSA groupings for different configuration tables (e.g., absences/attendances, work schedules, quotas, and wage types).

Figure 5

How to use table fields for employee selection in PCRs

This example shows how the same approach is used in the configuration of the employee eligibility rule as in the TE schema. The data element MOURA is set as a selector and represents the PSA grouping for the user-specified subject area (e.g., vacation accrual rules or overtime) that cannot be configured through SAP configuration tables. The values of fields can be retrieved via the SAP system’s standard operations and used for decision making in PCRs.

Some fields in table T001P are obsolete in current releases (e.g., MOURA – PSA grouping for leave types as infotype 0005 [leave entitlement] is replaced in current releases with infotype 2006 [absence quota]) or are not used in a majority of configurations (such as MOSTA – statistics modifier).

Though table T001P contains three reserved/unused fields, it is not a good idea to use reserved fields as they may be used in future SAP releases. If there is a need to retrieve more fields, you can create custom tables similar to table T001P and retrieve from that table as many fields as needed.

This table-centric employee selection rule configuration helps avoid tedious TE schema and PCR reconfiguration, analysis, and modification as all changes are done in tables and no changes in TE schemas or PCRs are required.

How to Make Your TE Schema Country-Specific

In global SAP implementations it is common to use different executable schemas for different countries. This is done because time evaluation is run by different departments at different times.

However, TE schemas and PCRs (unlike payroll rules) cannot be assigned to be executed for specific countries only. This can create a situation in which a TE schema can be mistakenly executed for employees from different countries. In this case, time evaluation results — and, subsequently, payroll — can be compromised. The situation can be unpredictable because time evaluation results can be changed retroactively, due to the uncertainty of the earliest recalculation date. Such results would not be automatically corrected and can cause errors in payroll.

Some simple steps to avoid this situation are outlined in Figure 6. Basically, it is possible to make the TE schema country-specific and completely exclude errors caused by executing the TE schema developed for a different country. Country-specific TE schemas check the country of the employee and the execution is terminated if the schema is run for an employee from a different country. It can be done in a simple PCR.

Figure 6

Country-specific TE schema configuration

In the first step the operation returns the country code for the employee who is being processed. If the employee’s country code (field MOLGA) does not match the country set in the TE schema, then the schema execution is terminated and no data is updated for that employee.

A similar approach is taken for excluding the running of incorrect SAP-delivered schemas (e.g., TM00), which can result in mistaken execution and creation of mistaken time evaluation results. To make this fix, simply select the Schema can be executed check box under Attributes. This prevents the running of the incorrect TE schema (Figure 7).

Figure 7

Prevent schemas from mistakenly executing

Developing Efficient PCRs

If you look at the PCR structure you may notice that each PCR contains different sections in two fields (Figure 8).

Figure 8

Sections of a PCR

One field (ABART) is a one-character field (employee subgroup grouping for personnel calculation rule – EESG), the second one (LGART – time type/wage type) is a four-character field (circled in Figure 8). The same structure is found in PCRs; correspondingly these fields are used in payroll as well. In time evaluation you can use these fields for structural development of efficient PCRs.

In general, the problem is that the SAP system does not provide a convenient technology to develop customer-specific PCRs. For example, it does not provide versioning control, configuration back-up mechanisms, or automatic change-tracking mechanisms. These technologies are extremely important when the functional sections are complex and require many sub-processes to be configured.

One of the problems is navigation between PCRs. SAP offers two operations, GCY, Go to Cycle, and PCY, Process the Cycle, which are approximately equivalent to the GOTO subroutine and CALL subroutine operations in any programming language.

The difference between these two operations is that the process flow does not return to the call of entry when you use the GCY operation, but does return back when you use the PCY operation. Therefore, there could be nested PCRs after several calls (note that the SAP system does not allow more than four nested PCRs from the original call).

If the user uses different PCRs that are called subsequently, then the structure of the TE schema becomes more complicated and the number of PCRs is increased. This is a common situation when the time evaluation configuration contains several hundred — if not thousands — of PCRs.

The extra challenge is that the SAP time evaluation module does not allow the data flow in one ESSG section when, after the execution of processes 2 and 3, the system executes process 4 in the same EESG section of the PCR (Figure 9).

Figure 9

Data flow that PCRs do not support

If you put process 4 in a different PCR then every time you make changes in the PCR you have to make changes in all the nested PCRs. Even a simple copying or cloning of the nested set of PCRs becomes a complex exercise. The number of PCRs is doubled and each PCR requires additional editing and, subsequently, additional testing and maintenance.

However, there is an operation — PAYTP x (set employee subgroup grouping for PCRule) — that is equivalent to GCY but provides a navigation inside the same PCR. In this operation, x is a parameter that defines the section of PCR that should be processed after the operation PAYTP. If you use operation PAYTP x then the structure of the PCR is as shown in Figure 10 — i.e., process 4 is located in EESG section 1 of the same PCR.

Figure 10

Data flow that PCRs support

This simple approach allows you to:

• Keep configuration related to the same subject area in one PCR
• Structure your configuration by allocating functional blocks in different sections
• Avoid unnecessary code corrections when copying PCRs
• Reduce the number of PCRs in your time evaluation project

Now you can include all the necessary processes related to the same functional areas into a small number of PCRs and your configuration is well structured. If you need to create a clone of the processes related to the same functional area, then you just need to copy one PCR because it instantly keeps all corrections/navigation.

The number of PCRs in your time evaluation project is significantly reduced and there is no need to keep identical PCRs just because they are used in different business flow processes. The extra benefit of this approach is that during time evaluation execution, lines of code in different sections of the PCR are highlighted only if they are executed for a particular employee (Figure 11). This makes debugging and analysis simple and efficient. At any time during debugging you can switch between the time evaluation log screen and the PCR code screen to check all sections of the PCRs.

Figure 11

Only executed lines are highlighted in the time evaluation log

Your PCR may contain as many PAYTP x operations as necessary to address the corresponding EESG sections of the PCR (Figure 12). You may use not only alphanumeric characters but also special characters to define the EESG section.

Figure 12

One PCR can include as many EESG sections as needed

If there is a need to go to a specific section of the PCR from a different PCR it is easy to do so using operation GCY yyyyX (where yyyy is a name of the PCR and X is a one-character field for the EESG section).

The only limitation in time evaluation is that it is not possible, when using operation PAYTP, to use the parameters A and S if you want to go to sections A and S.

PAYTP with parameter A does not redirect the data flow to section A. Instead, it redirects the data flow according to how it is defined in the table V_503_B (employee subgroup grouping for PCRs). You must be very careful when making changes in this table as this table is owned by payroll (not time management) and it is not country specific — any changes made in this table impact the settings for all the countries defined in the system.

Operation PAYTP with parameter S is used only if you want to go to the EESG section as defined in infotype 0050 (time recording information). If you use PAYTP S, ensure that infotype 0050 exists for all employees or there may be a runtime error during time evaluation execution.

For efficiency in complex time evaluation configurations follow these rules:

• TE schemas and sub-schemas should be well structured. To achieve this consider applying the site-centric principle vs. the functional-centric principle. In this case the employees’ selection rule may be allocated in one configuration block and, correspondingly, all changes can be addressed in the same places. In addition such separation simplifies changes in different contracts to be applied to time evaluation configuration and makes maintenance easier and more effective as different people may concentrate on different site-specific areas.
• If you use table-centric methods (basically, no hard cording of employee eligibility rules) then the configuration is even more consistent and maintainable. I discussed how to use the standard table and obsolete fields but there is no limit to the use of custom tables or other fields. It is important, however, to keep track of any structural changes outside the time evaluation configuration
• To prevent mistakenly running the wrong TE schemas, simply execute the PCR that disallows the execution of a TE schema for the wrong employees. In this way, you can avoid having to correct time evaluation and payroll results.
• Use the available PAYTP operation to significantly reduce the number of PCRs in your time evaluation configuration and to make it well structured.

All these routines make your configuration more sustainable. Applying these methods allows you to deliver a better and more understandable time evaluation solution and, at the same time, maintain the existing one in a simple, cost-effective manner.

Daniil Serebrennikov

Daniil Serebrennikov is a managing partner of VTMSoft LLC (a consulting and development company founded in 2009 by several former SAP high-level professionals, consultants, and software developers). He has been working in SAP ERP HCM projects (Time, PA, OM, and Payroll) since 1998 focusing on complex global and customer-specific solutions, primarily in SAP Time Management. Daniil’s previous experience was with SAP AG, several large consulting companies, and clients in different industries: oil, entertainment, utilities, mining, and the public sector. He also frequently speaks at SAP HR conferences.

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