Most companies I have worked with that use SAP Time Management end up creating an entire collection of customized time types. In most cases, this customization (and extra effort) is not necessary because the standard time types provide a lot of information and help make decisions about your own logic or reporting. Using the standard time types, instead of creating new ones, allows for more efficient creation of customized rules, as well as providing standard reporting options of which you may not be aware. For example, you can run a standard report to get all the similarly grouped attendance hours for an employee over the course of a period, such as a calendar year.

Using examples like this, I explain the standard functionality of time types, and discuss the logic in SAP-delivered schema TM04 for time evaluation with clock times. (Sschema TM00 is available if you are using time evaluation without clock times, and has many of the same attributes and rules as schema TM04, but is not discussed in this article.) I also explore the flexibility of configuration that is available for changing the delivered time types. Finally, I also cover the details for exactly how the delivered configuration creates and calculates these time types.

Understanding SAP Time Management Time Types

Time types assist with the necessary calculations in time evaluation. These time types can be stored with daily, weekly, monthly, annual, or lifetime values. Many organizations use time types to report on balances and totals based in their system. An example of a time-type calculation would be calculating overtime. There are multiple ways for calculating overtime pay.

For example, overtime might be paid for hourly employees after 40 hours have been worked in a week. To track this in time evaluation, the number of hours worked in a week is tracked in a time type. This time type is cleared at the beginning of every week to ensure that the calculation is correct. In another scenario, you might pay overtime after eight hours have been worked in a day. To do this, you would use a different time type to calculate the hours worked in a day, and it would be cleared at the beginning of each day. The attributes that are defined in configuration determine how the time types behave and are tracked.

From these examples, you begin to understand the different time types and you quickly realize the large role they play in SAP Time Management tracking and reporting. Here are a few examples of metrics that can be built, tracked, and stored in time evaluation via time types:

• Total hours worked in career (lifetime value)
• Total hours worked in year (annual value)
• Total vacation days taken on Friday (lifetime value)
• Total vacation days taken on a Monday (annual value)
• Total sick days before a holiday (lifetime value)

SAP delivers many time types as part of a standard implementation that can be used for common calculations and reporting abilities across most enterprises. Unlike other configuration items, such as primary wage types in payroll, you don’t need to copy and revise SAP-delivered time types—most work out of the box.

Time types are to time evaluation what technical wage types are to payroll—they are used in the calculation by the standard SAP schema, and you can and should keep those time types in your schema to maximize the value of your SAP system. Even if the delivered times types do not provide the exact functionality that you are looking for, they provide the framework for building the exact functionality that you need, without much effort. You can simply copy the delivered time types, copy the delivered SAP rule for filling the time types, and add the logic for your company time type within the updated company-specific rule.

Ideally, when you start an implementation, your consulting team should determine the relevant metrics to track. You can then use time types to build, track, and ultimately report on these metrics. Once you are post-go-live, you should revisit these metrics and determine if any changes or additions should be made. If you have already implemented SAP Time Management without consideration of which metrics are important to your organization, it is still not too late to build them into an implemented system later on.

Time Type Configuration

Let’s take a look at the configuration of a time type. To create a new time type or view the attributes of an SAP-delivered time type, go to the SAP IMG via transaction SPRO. Once there, follow menu path Time Management > Time Evaluation > Time Evaluation Settings > Define Time Types or view V_T555A from transaction SM30. In the screen that opens (not shown) you can see all the time types defined in your system. To access the attributes screen for any of these time types, simply double-click the desired time type, and the screen for the selected time type opens.

The time types from 0 to 1999 are reserved for SAP; any other number or letter combination can be used by companies to create customer time types in their system  (the most common format is Z****.) Let’s take a look at two time types—0900 and 0903—and review their attributes. First, let’s look at standard time type 0900 (Figure 1), which is used to calculate daily overtime after a defined amount of hours (for example, after 10 hours have been worked in one day).

Figure 1

Attributes of time type 0900

The SAP system offers a tremendous amount of flexibility with this time type. Because it is not a hard-coded value, but determined dynamically during the Time Evaluation run, its threshold can be dynamic based on variables such as work schedules or union agreements.

Let’s take a look at all the potential attributes of this time type and each of the fields.

• Save as day balance: If number 1 is in this field, it tells the system to store this in the database as a day balance in table ZES.
  ZES is a Time Management cluster table that stores the amounts in a time type at a daily level. For example, if you are tracking daily overtime, then 01/01/2016 could have a value such as eight hours for that specific day, and 01/02/2016 would have a value such as 10 hours specific to that day. These tables are stored in the cluster and can be viewed via standard SAP reporting (discussed later in this article).
• Cumulate in period balance: If number 1 is in this field, it tells the system to store this in the database as a period balance in table SALDO.
  SALDO is a Time Management cluster table that stores the amounts in a time type at a cumulative level depending upon the configuration of the time type. For example, if you are tracking weekly overtime, then 01/01/2016 could have a value such as eight hours from the first day, and 01/02/2016 could have a value such as 18 hours, which makes up the first two days. These tables are stored in the cluster and can be viewed via standard SAP reporting (discussed later in this article).
• Transfer prev period: If number 1 is in this field, it tells the system to transfer the value in this time type across periods. (In the delivered system a period is one month, so transferring across periods means moving the amount from January to February.)
• Transfer prev year: If number 1 is in this field, it tells the system to transfer the value in this time type across years. (Transferring across a year means moving the amount from 2016 to 2017.)
• Period bal. prev. period: Use this field if you want to move the value to a different time type at the end of each period. (A period is defined as a month in the standard system.)
• Period bal prev. year: Use this field if you want to move the value to a different time type at the end of each year. (In this case, the period is defined as a month in the standard system.)
• Store for time accounts: Use this field if you want to have the time type balances stored in database table ST. This allows balances to be downloaded to a time-recording system so that employees can view their balances.

Now let’s take a look at the attributes of the second standard time type in the example—0903—shown in Figure 2.

Figure 2

Attributes of time type 0903

This particular time type is used to calculate overtime for a week. In the US, this would be any hours worked over the standard 40-hour workweek. This time type is stored as a day balance in the ZES cluster table. It is stored as a period balance in the SALDO table and transferred across periods and across years. Given the task of this time type, these attributes make sense. You also need to know the amount that was in the time type from the previous day. For example, if it’s a Tuesday and the work week started on Monday, you need to know if there were overtime-eligible hours on Monday. You also need to transfer across periods because certain weeks could span over two months (e.g., 03/28/2016 to 04/02/2016), so you need to make sure to have that data available. In the same manner a particular week could also span over two years (e.g., 11/28/2016 to 12/03/2017).

For this time type, you need to reset the value every week to make sure the calculations are correct, but this is done dynamically in the time schema during run time. Once again, the SAP system does this intentionally to give you additional flexibility because a work week could be different based on your country or union agreement (for example, a workweek could begin on Monday for some employees and Sunday for others).

How Delivered Time Types are Created in Standard Schema TM04

Now that you understand what times types are, and how they are used by the SAP system, let’s take a look at some of the SAP-delivered time types and the information they contain. (There are additional time types that are used for calculations that are not mentioned here as it would be impossible to discuss in detail all the standard time types used in processing.) I show how these time types are created in the rules, and how they can be used for your own reporting or to help make decisions in your own schema rules. This can save a significant amount of time, effort, and cost because you don’t have to create custom time types and the logic to fill them—you can simply use standard ones. This allows you to maintain a more simple and standard schema that does not contain as many custom rules.

First, I am going to show an example of a calculated time type time—0600—that can be used to make decisions about how your time evaluation process should work. For example, you might decide to pay a bonus if an employee works on the holiday. To make that happen, you need to understand if the day being processed is a holiday. The example time type (0600) contains holiday hours and answers this question: is the day being processed a scheduled holiday? This particular time type is created in rule TE20.

Let’s take a look at rule TE20 in the Time Management log. To view this, go to transaction code PT60 and run time evaluation (with the Display Log option checked; not shown here). This rule is called in the day-processing portion of schema TM04 in the Errors checks block, as shown in Figure 3.

Figure 3

Schema location of rule TE20

The processing logic of this rule is shown on a scheduled holiday that the employee does not work and does not have an absence (Figure 4).

Figure 4

Processing logic of rule TE20

In this scenario (Figure 4), this rule fills time type 0600 via operation ADDDB0600T. This operation fills the time type with the scheduled hours in the day (eight hours). However, it takes a different path if it is a free-day holiday versus a scheduled holiday, or if the employee works or has an absence entered on that day. I do not show the variables for each scenario, but the instances in which time type 600 is filled in this rule are as follows:

• A scheduled holiday on which the employee does not work and does not have an absence entered
• A scheduled holiday on which the employee works
• A scheduled holiday on which the employee has an absence entered

Now you know how and when this time type is filled, it is easier to understand how to use it. If, in the future, you want to make a decision based on paying an employee on a scheduled holiday (regardless of whether an absence or attendance is also entered on that day), you can check time type 0600 to see if it has a value. Without this information, you need to create a custom rule and then fill the custom time type with the rule. Once it is created, you can use that custom time type to make your decision.

Next, let’s take look at a few standard reporting time types that you can use to gather information about the time and attendance of your workforce.

Before looking at the schema rules that create the standard time types (as in the previous example), let’s review the absence and attendance configuration that controls how the schema rules behave. This way, you can dictate the standard time types that are filled by the standard schema rules based on your configuration. Again, execute transaction code SPRO and then follow menu path Time Management > Time Evaluation > Time Evaluation without Clock Times > Time Data Processing > Assign Time Types and Processing Types. Alternatively, you can access view V_554S_E via transaction code SM30. This opens a screen like the one in Figure 5. Once this Choose Activity screen opens, you can select the appropriate sub-activity for both absences and attendances.

Figure 5

Access sub-activities to group absences for time types

In this case, double-click the Determine Processing Type/Time Type Class for Absence activity. This opens the screen in Figure 6 where you can group your configured absences using the P/T (Process Type/Time Type) field. In this example, all the paid absences are in group 01 and the unpaid absences are in group 02. You can, however, group your absences and attendances based on what makes the most sense for your organization.

Figure 6

Groupings for absences

The relationship of the P/T grouping with the time types that these absences fill is based on a combination of where the entry comes from (clocking/work schedule versus absence versus attendance) and which P/T field is assigned.

Below are the delivered keys, based on where the entry comes from, for the system to fill the TIP table during the processing of time evaluation. (This is discussed in more detail later in the article, when I explain how the system processes the TIP table).

• 1 = Clocking from infotype 2011 (for work schedule)
• 1 = Clocking from infotype 2011 (for positive time management)
• 1 = Work schedule for negative time (assumed hours)
• 2 = Absences from infotype 2001
• 3 = Attendance from infotype 2002

To summarize, if you have an absence from P/T group 01 it would be counted towards time type 1201, with the 2 denoting that it came from an absence and the 01 denoting it came from a P/T grouping of 01. If you had an attendance from group 02, the entry would count towards time type 1302. Clockings or entries imported from the work schedule are not defined in a table and are assigned a P/T value of 00, which, as a result, would cumulate into time type 1100.

These time types are SAP-delivered and, by default, are the ones created in time-evaluation processing. If you want to change how the system decides which time types should be created, you need to review the last step of the sub-activity configuration, Assign Processing Type and Time Type (table T555Y), shown in Figure 5.

Figure 7

Assign processing type and time type according to attendance/absence class

Table T555Y can be confusing until you understand how it works. Its layout is unlike most SAP configurations, as it contains keys and information from multiple places. Let’s take a look at each key field (e.g., the PSGpg, Group, and P/T columns).

The PSGpg Column

This field comes from the Grouping of Personnel Subareas for Time Recording activity. Follow IMG menu path Time Management > Time Evaluation > Time Evaluation Settings > Set Personnel Subarea Groupings for Time Recording or view V_001P_H from SM30.  

In the screen that opens (Figure 8), you can group different employees based on personnel area and personnel subarea differently so that they can have different time types assigned based on the values stored in their employee master data.

Figure 8

Configuration for grouping personnel subareas for time recording

In this example, if the employee is in 3300 and 0001, then he is assigned a value of 01. Personnel areas 3400 and 0001, as well as 3500 and 0001, are grouped with the same values, although this can be changed if you want them to behave differently.

The Group Column

This field comes from a Time Management schema rule, TMON, based on the assigned value in field MODIF T. Figure 9 shows the standard rule for an hourly employee who is set to grouping 02.

Figure 9

Rule TMON in the Time Management schema

The reason that SAP provides multiple groupings to classify employees is because using rule TMON you have the ability to further differentiate a variety of groups beyond the personnel area and personnel subarea. Using custom schema rules, you can determine what grouping an employee falls within. This is often necessary for union agreements, which may not be based on the personnel area and subarea combination.

The P/T Column

The last field comes from the configuration in Figure 6. It is based on how you want the absences and attendances to be grouped (based how you want them to behave).

Let’s take a look at how the time types in Time Management table TIP are filled using standard function TYPES in combination with table T555Y (Figure 7). To demonstrate this, I have created test data to give an employee a half-day absence, a half-day attendance, and run-time evaluation via transaction PT60. The output is shown in Figure 10.

Figure 10

Input of TYPES function showing absence and attendance

Figure 11 shows the processing of function TYPES, and how the system takes the input, uses table T555Y to determine the values, and then outputs the value of table TIP.

Figure 11

Input, processing, and output of TYPES function

The employee in this example is grouped into a PSGpg value of 01 (based on his personnel area and personnel subarea, shown in Figure 8) and had a TMON value of 02 (Figure 9). Both the absence and the attendance were grouped into value 01 for the P/T field (Figure 6).

As a result, the system found the matching entry on table T555Y that it needs to update the TIP values. The system then used the first P field to make a decision on how to process this on the TIP table, and which value to derive (pair type), highlighted in Figure 11. If the first P field has a value of 1, then table TIP pulls the values from fields PTyp 1 and TTyp 1. If the value is 2, then the table pulls the value from fields PTyp 2 and TTyp 2; if the value is 3, then the table gets the value from fields PTyp 3 and TTyp 3.

The value of the first pair type, which is set as it’s an SAP-delivered value, is determined based on whether the entry was imported from a clocking/work schedule, an absence, or an attendance. You can see the values imported below:

• 0 – Un-recorded absence or employee is on break (based on break schedule configuration)
• 1 – Employee is at work (record is imported to time evaluation using function P2011 or P2000)
• 2 – Employee is absent with approval (record is imported using function P2001)
• 3 – Employee is at work or working off-site (record is imported using function P2011 or P2002)

Understanding Schema Processing for Reporting Time Types

The next step is to explore how the delivered schema rules fill these standard time types. This is critical to understand how you can use these for reporting in your organization. Thus far, you have learned about the values in table TIP for time types. To report on these time types, however, they need to be moved over to table TES. Based on the configuration (shown in Figure 2), each individual time type needs to be stored at daily, monthly, annual, and lifetime balances in tables ZES and SALDO.

Rule TR11 is the SAP-delivered rule for moving the values from table TIP to table TES. Rule TR11’s job is to form day balances. This rule is called in the Manage time accounts block of the schema processing (Figure 12).

Figure 12

Schema location of rules TR11 and TR30

Rule TR11 is a unique rule in the fact that it holds only the explicit time types that the rule processes in the configuration of the rule. As a result, this rule is processed for only those time types. The time types called in the configuration of this rule are shown in Figure 13. Every other rule that processes the TIP table delivered by SAP is a generic call of the rule that processes every entry in the TIP table and does not have the time types explicitly mentioned in the configuration of the rule.

Figure 13

Time types processed in rule TR11

Now let’s see what the processing looks like. You see that processing this rule creates balances using operation ADDDB to form larger balances and totals. This is shown in Figure 14.

Figure 14

Processing and output of rule TR11

Not all the jobs are shown in Figure 14, but the job of this rule is to create balances. After these rules are processed, you are left with some big balances that you can report on. Here are some examples:

• Time type 0003 – Contains all absences/attendances/clockings
• Time type 0010 – Contains all clockings/work schedule values from infotype 2011 or infotype 0007 for positive time management employees who only enter exceptions
• Time type 0020 – Contains all absences from infotype 2001
• 0030 – Contains all attendances from infotype 2002
• Time type 1100 – Comes from clock times from infotype 2011 or from work schedules, depending on if you use positive time management or negative time management
• Time type 1201 – All absences grouped together in grouping 01. (All paid absences in my example, this can be customized.) This comes from absence hours entered on infotype 2001 that are grouped together in group 01, which was shown in Figure 6. You can create your own groups, which go to Time Types 1202, 1203, 1204, and so on, to create subset of absences (e.g., sick absences versus jury duty absences, discussed later in this article).
• Time type 1301 – All attendances grouped together in grouping 01. This comes from the attendance hours entered on infotype 2002. This was mentioned previously, but you can create your own groups which go to Time Types 1302, 1303, 3204, and so on, to create a subset of absences, such as training attendances versus on-site absences (discussed later in this article).

Now that the values have been moved from table TIP table to table TES, the delivered rules create additional balances based on these values. This is done in schema rule TR30, which is processed after TR11 in the Manage Time accounts subschema (shown previously in Figure 12).

Let’s take a look at what the processing looks like. This rule processes the example (created above) to create balances by filling values, such as the scheduled hours, using HRS=S, taking values from existing entries in the TES table using operation ADDDB, and then cumulating the values to other time types to form additional balances and totals. This is shown in Figure 15.

Figure 15

Processing and output of rule TR30

After this rule processes, you are left with the following additional time type balances. (There are additional time types that are created by this rule that are not discussed in this article.)

• Time type 0002 – Scheduled or planned hours. This comes from infotype 0007 (work schedule rule for daily working hours) defined in configuration; this can vary from day to day based on your schedule.
• Time type 0005 – Flextime balance. This is time type 0002 – 0005 + 0003. It contains scheduled hours minus absences.
• Time type 0050 – Productive hours in a month. This is time type 0010 + 0030; clockings + attendances.
• Time type 0051 – Cumulative productive hours in a year. This is time type 0010 + 0030; clockings + Attendances

Now that you have these balances and totals, you can start to think about the reporting of these wage types. Because the data is already stored, here are some examples of questions to which you can get answers:

• How many hours of paid absences were paid in X period? (Stored in time type 1201.)
• How many hours of productive work were in X period? (Stored in time type 0050, for monthly, and stored in time type 0051, for annual.)
• How many hours of unpaid absences did X employee have this year? (Stored in time type 1202.)

Reporting on the Values in Standard SAP Time Types

Once time evaluation has processed, and the results are stored in the time clusters, you can report on the values of the time types using either standard SAP tools or by creating your own. One of the tools available for reporting at an individual level is transaction code PT66. Execute transaction code PT66, and, in the screen that opens (Figure 16) enter the relevant details for this example: the Personnel number, Year, and Period.

Figure 16

Entries for transaction code PT66

Once the report is executed, the system returns the different time evaluation periods from which you can make a selection (Figure 17).

Figure 17

Initial output of transaction code PT66

Once you have this output, double-click the period that you want to look at. This opens up another screen (Figure 18), where you can further select what you want to look at.

Figure 18

Second output of transaction code PT66

From this screen, double-click the table that contains the data you’re looking for. In this example, let’s say that you’re looking for how many productive hours Pam Positive had in February 2016, and how many hours she has year to date.

Double-click table SALDO (because month-to-date productive hours are in time type 0050 and year-to-date productive hours are stored in time type 0051). This opens a screen like Figure 19 where you can see these details.

Figure 19

Output of the SALDO table for 02/2016 in transaction code PT66

Another SAP-delivered report that you can use for multiple employees is PT_BAL00. On this report, you can select the period and personnel numbers and then enter time types (Figure 20). This allows a lot of flexibility to search for and find particular values. The output is in SAP List Viewer (ALV) format, so it can be easily exported into Excel for further analysis.

Figure 20

Selection screen for report PT_BAL00

Once run, the system gives you the ALV output of the values. As shown in Figure 21, you can see how time types 0050 and 0051 work together to track productive and cumulative productive hours. This report can be run for a large population and sorted and filtered based on your specific requirements.

Figure 21

Output of report PT_BAL00

Imran Sajid

Imran Sajid is a Senior Education Consultant at SAP based in the Atlanta, GA, area. At SAP, he focuses on teaching classes in the HCM area within both SAP and SuccessFactors. Previously, Imran was a consultant who implemented and provided post-go-live support for more than a dozen different client systems spanning many industries, including manufacturing, automotive, retail, information systems, the public sector, and energy. He is the author of the book entitled, The Payroll Control Center for SAP ERP HCM and SAP SuccessFactors, as well as a frequent contributor to SAP Experts, where he has published almost a dozen articles. Imran is also frequent blogger on SAP Community Network (SCN). He graduated from the Georgia State University Robinson College of Business with a degree in Computer Information Systems. Imran can be found on Twitter @ImranSajidSAP.

You may contact the author at Imran.Sajid@sap.com.

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