2007 Sep 07 4:28 PM
Hi,
If I need to retrive data from 2 or more infotypes in HR then which one is the best way to use.
Thanks in advance.
Regards
Anil
Hello Arya
The Wiki coding was taken from a customer report where I just needed to fetch some infotype data (without any AUTHCHECK).
However, method GET_INFOTYPES (of CL_PT_EMPLOYEE) has an IMPORTING parameter I_NOAUTHCHECK which, by default, is initial (i.e. it does check the authority).
In order to use the LDB selections you have to write a report. Yet instead of using the LDB specific statements (like GET) you may find it easier to use class CL_PT_EMPLOYEE.
Regards
Uwe
2007 Sep 07 4:37 PM
in attributes of program, give PNP as logical database.
in program, write following code:
***********************************************
tables : pernr.
*--specify what all infotypes u want.....
infotypes : 0001,0002.
start-of-selection.
get pernr.
provide pernr bukrs from p0001
vorna nachn from p0002
between pn-begda and pn-endda.
write 😕 p0001-bukrs,
p0002-vorna,
p0002-nachn.
endprovide.
*************************
similarly include all infotypes and fields u need.
Regards
vasu
2007 Sep 07 4:42 PM
Hello Anil
Have a look at my Wiki posting
<a href="https://wiki.sdn.sap.com/wiki/display/Snippets/UnifiedAccesstoAllHR+Infotypes">Unified Access to All HR Infotypes</a>
Perhaps it may be useful.
Regards
Uwe
2007 Sep 07 5:47 PM
Nice work Uwe.. I guess your report doesn't use PNP.. how do you get the Sel Screen that comes up with PNP? design it in the report? What about the STd Authn checks that take place in the LDB? are these checks embedded in the Methods or do we need to explicitly code them in the report?
Regards,
Arya
2007 Sep 08 8:57 PM
Hello Arya
The Wiki coding was taken from a customer report where I just needed to fetch some infotype data (without any AUTHCHECK).
However, method GET_INFOTYPES (of CL_PT_EMPLOYEE) has an IMPORTING parameter I_NOAUTHCHECK which, by default, is initial (i.e. it does check the authority).
In order to use the LDB selections you have to write a report. Yet instead of using the LDB specific statements (like GET) you may find it easier to use class CL_PT_EMPLOYEE.
Regards
Uwe
2007 Sep 07 4:56 PM
Combination of joins and projections is best option for that.
<b>Join</b>
A join processes records from two or more infotypes. The data from these infotypes is provided
for a specific partial period.
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.
<b>Projection</b>
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 a 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 1996 - December 1996:Programmer /personnel area 1
January 1997 - December 1997:Programmer /personnel area 2
January 1998 - December 1998: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.
BUKRS1 BUKRS2 BUKRS3 BUKRS4
Job x
P0001
Job x
To create meaningful evaluations and avoid redundancies, create logical views for infotype
records.
Select the infotype fields which 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.
<b>Join and Projection</b>
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.
<b><REMOVED BY MODERATOR></b>
Regards
Vasu
Message was edited by:
Alvaro Tejada Galindo
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |