Skip to Content
author's profile photo Former Member
Former Member

Regarding HR data retrival

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

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Sep 07, 2007 at 03: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

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Sep 07, 2007 at 03:42 PM

    Hello Anil

    Have a look at my Wiki posting

    https://wiki.sdn.sap.com/wiki/display/Snippets/UnifiedAccesstoAllHR+Infotypes">Unified Access to All HR Infotypes</a>

    Perhaps it may be useful.

    Regards

    Uwe

    Add a comment
    10|10000 characters needed characters exceeded

    • 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

  • author's profile photo Former Member
    Former Member
    Posted on Sep 07, 2007 at 03: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

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.