Regarding HR data retrival

[Former Member]

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

[Former Member]

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

[Former Member]

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

[uwe_schieferstein]

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

[Former Member]

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

[uwe_schieferstein]

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

[Former Member]

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