Functions TIMTP and TYPES are used in a time-evaluation schema to set two time-pair attributes — the processing type and the time type. I will demonstrate with examples how these two functions actually go about accomplishing this task. I will also show how the outcome of TIMTP and TYPES processing is used to generate wage types and to form time-type balances.

TIMTP and TYPES in the Schema

Functions TIMTP and TYPES are typically called from a time schema without specifying any parameters. Only one of the two functions must be used in any particular time-evaluation schema. Figure 1 shows how TYPES is called without any parameters.

Figure 1

Function TYPES called in schema TM04

Few parameters exist for these two functions. The most notable is the TIME parameter, which you can use with TIMTP. With this parameter, TIMTP skips over time pairs without start and end times.

The placement of TIMTP and TYPES in the schema is crucial. The functions should only be called after the time data in infoTYPES 2001, 2002, and 2011 has been imported with the relevant P functions (e.g., P2001). This is because TIMTP and TYPES operate on time pairs and time pairs are created by the P functions. (Data in infoTYPES 2012 and 2013 is not represented as time pairs; therefore, these infoTYPES can be imported even after TIMTP and TYPES are called.) Because TIMTP and TYPES prepare time pairs for wage type generation, they also need to be called before the GWT functions, which generate wage types from time pairs.

Tables T555Y and T555Z

TIMTP and TYPES are used in tandem with configuration in tables T555Z and T555Y, respectively. These two tables ultimately determine the outcome of the two functions. Only certain sections in these tables are used in a given schema, as determined by the following values:

• The validity start and end date. Only those table rows that encompass the day being processed are relevant.
  
  
• The personnel subarea grouping for time recording. Only those table rows that contain the time recording grouping of the employee’s personnel subarea are relevant. This grouping is configured in the IMG via menu path Time Management>Time Evaluation>Time Evaluation Settings>Set Personnel Subarea Groupings for Time Recording.
  
  
• The time-type determination grouping. The value of this field is determined in the time-evaluation schema’s initialization block. Personnel calculation rule (PCR) MODT does this in schema TM00 and PCR TMON in schemas TM01 and TM04. Both these PCRs use operation MODIF T to set this value. Figure 2 shows how this grouping is set to 02. With a setting of 02 only the rows in T555Y and T555Z for time-type determination grouping 02 are applicable.

Figure 2

MODIF T grouping set to 02 in PCR TMON during the initialization phase of schema TM04

How TIMTP Works

Now I’ll show how function TIMTP sets the processing type and the time-type attributes of a time pair. I’ll also demonstrate a third function of TIMTP, which is to split a time pair into smaller pairs — something TYPES does not do.

TIMTP requires as input a time pair (represented in time-evaluation table TIP) and the daily work schedule table (represented in time-evaluation table TZP). Figure 3 is a depiction of a time pair before TIMTP processing. This time pair shows a work entry, which starts at 8 am and ends at 6 pm.

Figure 3

Time pair before TIMTP in the time-evaluation log

The O attribute column indicates the origin of the time pair; the P value indicates the origin of the time pair as infotype 2002. The left-most P attribute column contains the pair type; value 3 also indicates that the data comes from infotype 2002. As described in the second article in this series, the other possible values for the pair type are:

• 0, which indicates time pairs representing non-recorded times. TIMTP, for example, generates time pairs of pair type 0.
  
  
• 1, which indicates time pairs from infotype 2011 or pairs generated from the current day’s shift with function P2000.
  
  
• 2, which represents absence time pairs from infotype 2001.

The daily work schedule table for the day on which this time pair exists is shown in Figure 4.

Figure 4

Daily work schedule table (TZP) in time-evaluation log

The TZP table on this day indicates that the employee is scheduled to work from 8 am to 12 pm, take a lunch break from 12 pm to 1 pm, and then work from 1 pm to 5 pm. The TIP and the TZP tables are the input to function TIMTP. The function changes the input time pair into the time pairs shown in Figure 5.

Figure 5

Time pairs after TIMTP processing

TIMTP performs its function in two steps. First it subdivides a single input time pair into several smaller pairs and sets the ID attribute for each of these pairs. It does this according to the daily work schedule in TZP. Then it also sets the processing type and time type for each of these time pairs, by using T555Z.

Here is an explanation of how the time pair in Figure 3 is split into several smaller pairs.

Think of the daily work schedule as a continuous time line that starts at midnight and ends at midnight (Figure 6). Then mark on this line the times where each of the rows in the TZP begins — at midnight, 8 am, 12 pm, 1 pm, and 5 pm. Annotate each of these time points with the time ID from the TZP table.

Figure 6

A time pair is split according to how it overlaps with the TZP

Imagine another line below this to represent the time pair. Mark this time line with the time points of the TZP. This causes the 8 am to 6 pm time pair to split into four pairs. This is in fact what TIMTP does to split the pair into four smaller pairs. In addition, it sets the ID attribute of each of these four pairs according to the ID of the corresponding TZP time point. For example, in Figure 5 the ID of the time pair that starts at 8 am is 02.

Once the time pair has been split according to the TZP, the next step derives the processing type and the time type. This is where T555Z comes in (Figure 7).

Figure 7

Table T555Z (this shows only the section of the table relevant to the example)

The T555Z rows relevant to my example have a value 01 for the PSG column and 02 for the Group column. These are the relevant rows because:

• The employee’s personnel subarea grouping for time recording (table column PSG) is 01
  
  
• The time-type determination grouping (table column Group) is 02 according to the MODIF T operation (Figure 2)

Note that each row has a different ID. This ID corresponds with the ID attribute of a time pair. The ID is used to determine which T555Z row is relevant for a specific time pair.

To the right of the End Date in T555Z are four columns — marked PairType0 through PairType3. Each lists a processing type (e.g., M, S, K) and a time type (e.g., 0310, 0110, 0510). TIMTP selects one of these columns for a time pair according to the time pair’s pair type.

The processing type and time type that are ultimately assigned to the time pair is determined by where the selected row and the selected column intersect. The following step-by-step explanation shows how TIMTP does this with the time pair from Figure 5 that starts at 8 am. (TIMTP will perform these steps for each of the time pairs in the input time pair table.)

Step 1. TIMTP finds the row in T555Z that contains the ID of the time pair. In the case of the 8 am time pair it is 02.

Step 2. It finds the pair type column that corresponds with the pair type of the time pair. In the example the pair type is 3, so the PairType3 column is selected.

Step 3. It finds the relevant processing type and time type where the selected row and column intersect. For the 8 am time pair this is processing type S and time type 0130, as shown in Figure 7.

For the Figure 5 time pair that starts at 5 pm, the time ID is 01 and the pair type is 3. Therefore, TIMTP assigns processing type M and time type 0330. Processing type M is traditionally used to denote overtime. This example shows how TIMTP automatically finds and flags an overtime time pair.

However, this example also demonstrates that if TIMTP is used, then an employee’s planned work schedule — as reflected in the TZP table — must closely correlate with the schedule the employee actually works. If the schedule assignment is not accurate, then TIMTP derives overtime pairs incorrectly.

How TYPES Works

Whereas TIMTP uses T555Z, function TYPES uses table T555Y to assign processing types and time types. As you’ll see, T555Z and T555Y look similar and they are interpreted similarly.

Unlike TIMTP, TYPES does not split time pairs into smaller pairs. This allows the assignment of a work schedule that does not precisely reflect the actual work schedule of an employee. What is gained in work schedule flexibility is lost in automation. However, this is easily remedied with PCRs that automate overtime determination. In any case, while TIMTP can automatically determine daily overtime, weekly overtime can still only be implemented with PCRs.

To explain how TYPES works, I’m again going to use the time pair in Figure 3. This pair is the input pair that was also used in the TIMTP example. However, as Figure 8 shows, TYPES processes it differently.

Figure 8

Time pair after TYPES in the time-evaluation log

Unlike TIMTP, TYPES does its processing with table T555Y, and the TZP is not used. As with T555Z, the relevant rows in T555Y are first of all determined by the employee’s personnel subarea grouping for time recording (column PS grpg in Figure 9) and the time-type determination grouping (column Group) as set by the MODIF T operation (Figure 2). In my example, these values are set to 01 and 02.

Figure 9

Table T555Y (showing only the section of the table relevant to the example)

Note that table T555Y has a P/T column, whereas T555Z has an ID column. P/T refers to the same setting that the CT attribute of a time pair refers to. This setting is the processing type/time type class of the absence or attendance record type from which the time pair originates. (More information about the processing type/time type class and how it is configured in table T554S is in part two of this series.)

To see how TYPES uses this relationship between CT and P/T, I’ve provided the following step-by-step example. As with TIMTP, these steps are followed for each time pair in the input time pair table (TIP).

Step 1. TYPES finds the row in T555Y that contains in the P/T column the value of the CT attribute of the time pair. In the case of the time pair in Figure 3, the CT attribute is set to 01. Therefore, the row that has 01 in the P/T column is selected.

Step. 2. TYPES then finds the pair type column that corresponds with the pair type of the time pair. In the example the pair type is 3, so the PairType3 column is selected.

Step 3. As with TIMTP, where the selected row and column intersect is where the relevant processing type and time type for the time pair is found. For the example time pair, this is processing type S and time type 1301, as shown in Figure 9.

In SAP time evaluation, you can automate overtime determination even if only one time record represents the total duration of work, as shown in Figure 3. To do this, PCRs are used after TYPES to split off an overtime pair from the regular time pair. R/3 has a template for this purpose in the time subschema TW15 and the PCRs it contains. Since only the starter schema TM04 uses TYPES, only TM04 includes subschema TW15.

Uses of the Processing Type

The processing-type attribute of a time pair plays an important role in how R/3 time evaluation generates time wage types. Once functions TIMTP and TYPES have set this attribute, time-evaluation function GWT can be used to generate wage types for time pairs. GWT does this in combination with table T510S configuration.

Figure 10 is an example of how function GWT is called in the starter schema TM04. It is called twice, first for processing type S and then for M. The first line generates wage types for time pairs with processing type S, and the next line for time pairs with processing type M.

Figure 10

Starter schema TM04 with two GWT calls

The two GWT lines can only generate wage types if a time pair exists with the processing type specified in the GWT call and if an entry exists in table T510S that specifies this processing type. In Figure 11, the T510S entry specifies model wage type MM00 for a time pair with processing type M. Actually, this wage type is only generated if all other conditions are also met, e.g., only if the day is not a public holiday. A full discussion of T510S falls outside the scope of this article.

Figure 11

Table T510S entry for an overtime wage type

Using the T510S configuration in Figure 11, the GWT M statement processes the time pair with processing type M in Figure 5 and generates wage type MM00.

Processing type S is traditionally used for normal working time, and M for overtime. However, customers can decide how to use the processing types delivered in the standard, and can also create their own processing types. You customize processing TYPES via the IMG menu path Time Management>Time Evaluation>Time Evaluation with/without Clock Times>Time Wagetype Selection and Overtime Compensation>Define Processing TYPES.

Uses of the Time Type

Time types are alternatively known as time variables, time balances, or time buckets. Time information, such as hours and minutes, can be stored in time types. However, any number, with certain limitations, can be stored in a time type (e.g., a count of how many days in a row an employee has worked overtime).

A time type can accumulate figures for a day or for a longer period of time, such as the number of hours worked in a week, the number of overtime hours worked on any particular day, or the number of days available in a vacation entitlement.

One of the primary uses of a time type is in reporting. Time-type balances are stored in the time results cluster from where reports can then extract this information. The report most commonly used to report on time-type balances is RPTBAL00.

In Figure 12 you can see the time types RPTBAL00 would show for the time pairs and time types from Figure 5. (Time type 0510 was converted to time type 0500 during time evaluation, with the standard time balance processing PCR TR10.)

Figure 12

Time-balance results with report RPTBAL00

For both TIMTP and TYPES the time types attached to time pairs need to be explicitly extracted and stored in time-type balances if the intention is to store them in the time results. Standard PCRs TR10 and TR11 accomplish this task. If PCRs like these are not used, then the time-type information contained in time pairs won't be stored in the time results.

TYPES and TIMTP in Starter Schema Selection

Table 1 provides a summary and a guideline for selecting the best starter schema for a time-evaluation implementation. In this last article, I showed how flexible work schedule environments, absence and attendance records, and overtime determination methods play a role in the decision about whether to use TIMTP or TYPES. Understanding this makes it possible to decide which starter schema is the most applicable.