Time Data (PA-PAD)
Reading Data
Infotypes 2000 to 2999 are time infotypes. They are stored in tables PA2000 to PA2999. Infotypes are declared with the INFOTYPE statement, and data is made available for processing in the internal infotype tables (infotype 2011 is an exception).
You should not load all time infotype records from the earliest to most recent system dates into the main memory. This would quickly lead to a memory overload, especially if a front-end time recording system is connected to your HR system.
This is why time data should be read only for a specific period.
Use the infotype declaration supplement MODE N to define that the internal time infotype tables should be declared but not filled at the GET PERNR event.
Later you can fill these tables using a statement with selection period parameters.
Use the following report to read time data:
REPORT RPABAP05.
TABLES: PERNR.
INFOTYPES: 2001 MODE N.
GET PERNR.
RP_READ_ALL_TIME_ITY PN-BEGDA PN-ENDDA.
LOOP AT P2001.
WRITE: / P2001-ABWTG.
ENDLOOP.
An ABAP macro reads the time data. This macro uses the data selection period parameter of the selection screen.
See also:
Processing Data
Due to the time constraint of infotypes, several special features must be taken into account when processing time data. Views of time data are generally not practical.
In time infotypes, data is determined on the basis of the validity period.
When you enter an absence record, the number of days of absence is calculated on the basis of the absence period.
In a view, new partial periods are created without any changes being made to infotype data. This would lead to incorrect results in time infotypes, since this data depends on the validity period.
For example, if, a leave record extends from the middle of January to the middle of February and 20 days of leave are calculated for this period, then a view for the month of February would result in a leave record which extends from the beginning to the middle of February. The number of days of leave would not have changed and the information would be incorrect.
In addition, in master data, the time constraint is a unique characteristic of the infotypes or subtypes. There are no time dependencies between the infotypes and subtypes.
Time data is basically different. Let us assume that an employee becomes sick during vacation. The leave record is then delimited on the first day of the sickness, and the sickness record follows.
Likewise, the system prohibits the entry of a leave record that coincides with a sickness record. The same also applies to overtime during a sickness.
The time dependency of time infotype records covers all infotypes and subtypes and is not limited to dependencies between records of one and the same infotype only.
The time constraint of time infotypes is not an attribute but is defined by the relationships between infotypes.
Moreover, certain time infotype records have specific clock-in/clock out times. Several records may therefore exist for one infotype on a particular day.
Since views require explicit data and this prerequisite is not fulfilled by time infotypes, you should not use joins and projections for time data.
Time infotype tables are processed with the LOOP statement since the PROVIDE statement limits, and thus changes, the infotype start and end dates to the data selection period.