ABAP HR
 | |  | |  | |  | |  | |  | |  | |  | |  |
Views/Join/Projection
Views Introduction
When evaluating data, we distinguish between the logical and the physical view.
The physical view corresponds to the form in which the infotype data is stored in the HR tables.
This data is stored in infotype records with a validity period.
In the logical view, the validity periods of individual fields are determined for several infotype
records. For example, for an evaluation, the time period during which an employee worked at a
particular job may be important, irrespective of whether a company code, personnel area or cost
center change occurred during this time.
Data from several infotypes can also be provided for a specific partial period. When calculating
partial payroll periods, it is especially important that data on basic pay, work schedule and cost
distribution are provided for the relevant partial period.
Join
A join processes records from two or more infotypes. The data from these infotypes is provided
for a specific partial period.
Example We would like to know in which time period an employee worked at which job and at
which address he or she resided during this time.
The following address data is available:
January - June Hamburg
June - December Munich
The following work center data is available:
January - April Programmer
May - December Course instructor
If the address and work center data are provided for specific partial periods, the following cases
result:
January - April Hamburg / programmer
May - June Hamburg / course instructor
July - December Munich / Course instructor
The ABAP syntax of this join is as follows:
PROVIDE * FROM Pmmmm
* FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA.
The partial periods for infotypes Pmmmm and Pnnnn as well as for all other infotypes of the join
are defined in the fields BEGDA and ENDDA.
The data of each infotype in the join must be available during the entire validity period of the
infotype. The time periods of infotype records may not overlap; therefore, the join may not
contain infotypes with time constraint "three".
The time periods of records overlap if an infotype is read without any subtype restrictions. For
example, the Address infotype has the subtypes Permanent residence, Temporary residence and
Home address.
Time periods will ultimately overlap if all addresses are read. Therefore, you must always select a
subtype for a join, and this subtype may not have the time constraint "three".
The program code for the above join for work center and address data is as follows:
REPORT RPABAP03.
TABLES: PERNR.
INFOTYPES: 0001, 0006.
GET PERNR.
PROVIDE * FROM P0001
* FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY eq '1'.
WRITE: / PERNR-PERNR, P0001-STELL,
P0006-STRAS, P0006-BEGDA, P0006-ENDDA.
ENDPROVIDE.
Sometimes no data is available for a particular infotype in the selected partial period. Infotype
validity periods may not overlap but gaps are permitted.
For example, gaps can occur when personal data is joined with address data:
Personal data
January 1960 - May 1998 Miller
May 1998 - December 1998 Smith
Address data:
January 1998 - December 1998 Hamburg
A join for personal and address data is presented as follows:
January 1960 - December 1997 Miller
January 1998 - April 1998 Miller / Hamburg
May 1998 - December 1998 Smith / Hamburg
Only personal data is available in the first partial period. Since the record does not provide the
required information, the join's function of providing data from all associated infotypes has not
been fulfilled.
The variables Pnnnn_VALID recognize that only incomplete data is available for a particular partial
period.
This variable is formed when the report is run for each Pnnnn infotype included in a join.
If data exists in the partial period for the Pnnnn infotype, the variable Pnnnn_VALID is filled with
X.
These variables are evaluated as follows:
REPORT RPDEMO03.
TABLES: PERNR.
INFOTYPES: 0002,
0006.
GET PERNR.
PROVIDE * FROM P0002
* FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY = '1'.
IF P0006_VALID EQ 'X'.
WRITE: / PERNR-PERNR,
P0002-BEGDA DD/MM/YYYY,
P0002-ENDDA DD/MM/YYYY,
P0002-NACHN,
P0006-ORT01.
ENDIF.
ENDPROVIDE.
A list is generated only if address data is available. The first partial period, for which only
personal data is available, is suppressed.
Projection
All data of an infotype is stored on the database with its period of validity.
When you change one or more fields of an infotype record, the system creates a new record
with a new validity period. The date on which you changed the record is the start date of this
new record.
Therefore, the data fields that are not affected by the changes contain the same data over
several infotype records and validity periods.
From a logical perspective, these fields are valid in all infotype records until they are changed.
When seen from this logical perspective, each field of an infotype has its own validity period.
This is illustrated in the following case:
An employee has worked as a programmer for three years in three different personnel areas.
The following organizational assignment data is available:
January 1992 - December 1992: Programmer /personnel area 1
January 1993 - December 1993: Programmer /personnel area 2
January 1994 - December 1994: Programmer /personnel area 3
If you only require the time period during which an employee performs a specific job and not his
or her personnel area for an evaluation, the following applies:
January 1996 - December 1998: Programmer
The physical view has three infotype records, the logical view one.
To create meaningful evaluations and avoid redundancies, create logical views for infotype
records.
Select the infotype fields that are important for the evaluation and disregard the others.
In the above example, the data in the other fields is invalid for the evaluation since it is unknown
which personnel area the employee belonged to from 1996 - 1998.
This view of the validity period of a group of infotype fields is known as projection.
The program code for the projection is:
PROVIDE <Field_1> <Field_2> <Field_n> FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA .
The infotype data for a projection must be available throughout the entire validity period. If the
time periods of certain infotype records overlap, the data cannot be clearly assigned to one
period.
Therefore, you should not use projections for infotype records with time constraint ‘three’. The
report for the above projection is:
REPORT RPABAP04.
TABLES: PERNR.
INFOTYPES: 0001.
GET PERNR.
PROVIDE STELL FROM P0001 BETWEEN PN-BEGDA AND PN-ENDDA.
WRITE: / PERNR-PERNR, P0001-STELL, P0001-BEGDA,
P0001-ENDDA.
ENDPROVIDE .
The logical validity for the activity period is included in the infotype BEGDA and ENDDA fields.
Join and Projection
You can combine the two logical views of infotype data, the join and the projection.
We read the data from several infotypes and create new partial periods. We select the infotype
fields that are important for the evaluation and combine these partial periods again.
The following example illustrates this.
An employee works as a programmer in the current year and marries in May. Her name does not
change.
Organizational assignment:
January - December Programmer
Personal data:
January - April Donna Debug - single
May - December Donna Debug - married
When the data from both infotypes is read concurrently, the result is:
January - April Donna Debug - single /programmer
May - December Donna Debug - married /programmer
Since we can disregard her marital status in the evaluation, we project on her first and
last names:
January - December Donna Debug / programmer
The following report exemplifies the above case:
REPORT RPDEMO04.
TABLES: PERNR.
INFOTYPES: 0001,
0002.
GET PERNR.
PROVIDE STELL FROM P0001
NACHN VORNA FROM P0002
BETWEEN PN-BEGDA AND PN-ENDDA
IF P0001_VALID = 'X'.
WRITE: / P0002-NACHN, P0002-VORNA,
P0001-BEGDA DD/MM/YYYY,
P0001-ENDDA DD/MM/YYYY,
P0001-STELL.
ENDIF.
ENDPROVIDE.
This report combines the associated validity periods and provides the data of relevant infotype
fields for a specific period.
Fields, which are not accessed, have their initial value in the projection.
Provision of data for a specific partial period is especially important for partial period factoring in
payroll.
If an employee's basic pay or the cost distribution changes during the payroll period, you must
calculate the salary proportionately for the resulting partial periods.
However, if the payroll administrator of the organizational unit changes, this has no effect on
payroll.
By linking a join and a projection, you can read the master data for a specific partial period.
Views Introduction
When evaluating data, we distinguish between the logical and the physical view.
The physical view corresponds to the form in which the infotype data is stored in the HR tables.
This data is stored in infotype records with a validity period.
In the logical view, the validity periods of individual fields are determined for several infotype
records. For example, for an evaluation, the time period during which an employee worked at a
particular job may be important, irrespective of whether a company code, personnel area or cost
center change occurred during this time.
Data from several infotypes can also be provided for a specific partial period. When calculating
partial payroll periods, it is especially important that data on basic pay, work schedule and cost
distribution are provided for the relevant partial period.
Join
A join processes records from two or more infotypes. The data from these infotypes is provided
for a specific partial period.
Example We would like to know in which time period an employee worked at which job and at
which address he or she resided during this time.
The following address data is available:
January - June Hamburg
June - December Munich
The following work center data is available:
January - April Programmer
May - December Course instructor
If the address and work center data are provided for specific partial periods, the following cases
result:
January - April Hamburg / programmer
May - June Hamburg / course instructor
July - December Munich / Course instructor
The ABAP syntax of this join is as follows:
PROVIDE * FROM Pmmmm
* FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA.
The partial periods for infotypes Pmmmm and Pnnnn as well as for all other infotypes of the join
are defined in the fields BEGDA and ENDDA.
The data of each infotype in the join must be available during the entire validity period of the
infotype. The time periods of infotype records may not overlap; therefore, the join may not
contain infotypes with time constraint "three".
The time periods of records overlap if an infotype is read without any subtype restrictions. For
example, the Address infotype has the subtypes Permanent residence, Temporary residence and
Home address.
Time periods will ultimately overlap if all addresses are read. Therefore, you must always select a
subtype for a join, and this subtype may not have the time constraint "three".
The program code for the above join for work center and address data is as follows:
REPORT RPABAP03.
TABLES: PERNR.
INFOTYPES: 0001, 0006.
GET PERNR.
PROVIDE * FROM P0001
* FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY eq '1'.
WRITE: / PERNR-PERNR, P0001-STELL,
P0006-STRAS, P0006-BEGDA, P0006-ENDDA.
ENDPROVIDE.
Sometimes no data is available for a particular infotype in the selected partial period. Infotype
validity periods may not overlap but gaps are permitted.
For example, gaps can occur when personal data is joined with address data:
Personal data
January 1960 - May 1998 Miller
May 1998 - December 1998 Smith
Address data:
January 1998 - December 1998 Hamburg
A join for personal and address data is presented as follows:
January 1960 - December 1997 Miller
January 1998 - April 1998 Miller / Hamburg
May 1998 - December 1998 Smith / Hamburg
Only personal data is available in the first partial period. Since the record does not provide the
required information, the join's function of providing data from all associated infotypes has not
been fulfilled.
The variables Pnnnn_VALID recognize that only incomplete data is available for a particular partial
period.
This variable is formed when the report is run for each Pnnnn infotype included in a join.
If data exists in the partial period for the Pnnnn infotype, the variable Pnnnn_VALID is filled with
X.
These variables are evaluated as follows:
REPORT RPDEMO03.
TABLES: PERNR.
INFOTYPES: 0002,
0006.
GET PERNR.
PROVIDE * FROM P0002
* FROM P0006 BETWEEN PN-BEGDA AND PN-ENDDA
WHERE P0006-SUBTY = '1'.
IF P0006_VALID EQ 'X'.
WRITE: / PERNR-PERNR,
P0002-BEGDA DD/MM/YYYY,
P0002-ENDDA DD/MM/YYYY,
P0002-NACHN,
P0006-ORT01.
ENDIF.
ENDPROVIDE.
A list is generated only if address data is available. The first partial period, for which only
personal data is available, is suppressed.
Projection
All data of an infotype is stored on the database with its period of validity.
When you change one or more fields of an infotype record, the system creates a new record
with a new validity period. The date on which you changed the record is the start date of this
new record.
Therefore, the data fields that are not affected by the changes contain the same data over
several infotype records and validity periods.
From a logical perspective, these fields are valid in all infotype records until they are changed.
When seen from this logical perspective, each field of an infotype has its own validity period.
This is illustrated in the following case:
An employee has worked as a programmer for three years in three different personnel areas.
The following organizational assignment data is available:
January 1992 - December 1992: Programmer /personnel area 1
January 1993 - December 1993: Programmer /personnel area 2
January 1994 - December 1994: Programmer /personnel area 3
If you only require the time period during which an employee performs a specific job and not his
or her personnel area for an evaluation, the following applies:
January 1996 - December 1998: Programmer
The physical view has three infotype records, the logical view one.
To create meaningful evaluations and avoid redundancies, create logical views for infotype
records.
Select the infotype fields that are important for the evaluation and disregard the others.
In the above example, the data in the other fields is invalid for the evaluation since it is unknown
which personnel area the employee belonged to from 1996 - 1998.
This view of the validity period of a group of infotype fields is known as projection.
The program code for the projection is:
PROVIDE <Field_1> <Field_2> <Field_n> FROM Pnnnn
BETWEEN PN-BEGDA AND PN-ENDDA .
The infotype data for a projection must be available throughout the entire validity period. If the
time periods of certain infotype records overlap, the data cannot be clearly assigned to one
period.
Therefore, you should not use projections for infotype records with time constraint ‘three’. The
report for the above projection is:
REPORT RPABAP04.
TABLES: PERNR.
INFOTYPES: 0001.
GET PERNR.
PROVIDE STELL FROM P0001 BETWEEN PN-BEGDA AND PN-ENDDA.
WRITE: / PERNR-PERNR, P0001-STELL, P0001-BEGDA,
P0001-ENDDA.
ENDPROVIDE .
The logical validity for the activity period is included in the infotype BEGDA and ENDDA fields.
Join and Projection
You can combine the two logical views of infotype data, the join and the projection.
We read the data from several infotypes and create new partial periods. We select the infotype
fields that are important for the evaluation and combine these partial periods again.
The following example illustrates this.
An employee works as a programmer in the current year and marries in May. Her name does not
change.
Organizational assignment:
January - December Programmer
Personal data:
January - April Donna Debug - single
May - December Donna Debug - married
When the data from both infotypes is read concurrently, the result is:
January - April Donna Debug - single /programmer
May - December Donna Debug - married /programmer
Since we can disregard her marital status in the evaluation, we project on her first and
last names:
January - December Donna Debug / programmer
The following report exemplifies the above case:
REPORT RPDEMO04.
TABLES: PERNR.
INFOTYPES: 0001,
0002.
GET PERNR.
PROVIDE STELL FROM P0001
NACHN VORNA FROM P0002
BETWEEN PN-BEGDA AND PN-ENDDA
IF P0001_VALID = 'X'.
WRITE: / P0002-NACHN, P0002-VORNA,
P0001-BEGDA DD/MM/YYYY,
P0001-ENDDA DD/MM/YYYY,
P0001-STELL.
ENDIF.
ENDPROVIDE.
This report combines the associated validity periods and provides the data of relevant infotype
fields for a specific period.
Fields, which are not accessed, have their initial value in the projection.
Provision of data for a specific partial period is especially important for partial period factoring in
payroll.
If an employee's basic pay or the cost distribution changes during the payroll period, you must
calculate the salary proportionately for the resulting partial periods.
However, if the payroll administrator of the organizational unit changes, this has no effect on
payroll.
By linking a join and a projection, you can read the master data for a specific partial period.
All of the product names here are trademarks of their respective companies. The site
www.allsaplinks.com no way affiliated with SAP AG. We have made every effort for the content
integrity. Information used on this site is at your own risk.
www.allsaplinks.com no way affiliated with SAP AG. We have made every effort for the content
integrity. Information used on this site is at your own risk.
| AllSapLinks.com |
