Help on ABAP HR

Former Member · ‎10-11-2007

Hi,

i learned ABAP HR can any body help me materials regardign this

any body having specifications regardsing ABAP HR it will be more helpfull to this id <b><REMOVED BY MODERATOR></b>

Message was edited by:

Alvaro Tejada Galindo

Former Member · ‎10-11-2007

Maybe this link can be helpfull

http://www.sapdevelopment.co.uk/hr/hr_infotypes2.htm

Have a look at http://www.sap-img.com/human/how-to-create-a-hr-infotype.htm, but have also a look at this thread

https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/t...

found this link probably can be helpful to someone

http://help.sap.com/saphelp_46b/helpdata/en/f7/2fe034ee251f34e10000009b38f83b/frameset.htm

http://sap.ittoolbox.com/groups/technical-functional/sap-hr/how-to-create-z-infotype-in-organization...

How to create a HR infotype?

1) Go to Transaction PM01.

2) Enter the custom Infotype number which you want to create (Should be a 4 digit number, start with 9).

3) Select the ‘Employee Infotype’ radio button.

4) Select the ‘PS Structure Infotype’.

5) Click on Create… A separate table maintenance window appears…

6) Create a PS structure with all the fields you want on the Infotype

7) Save and Activate the PS structure

😎 Go back to the initial screen of PM01.

9) Click on ‘All’ push button. It takes a few moments.

10) Click on ‘Technical Characteristics’. Infotype list screen appears

11) Click on ‘Change’(pencil) button

12) Select your Infotype and click on ‘Detail’ (magnifying glass) button

13) Give ‘T591A’ as subtype table

14) Give ‘T591S’ as subtype txt tab

15) Give your subtype field as subtype field

16) Save and come back to PM01 initial screen

17) Click on ‘Infotype Characteristics’ … Infotype list screen appears

18) Click on ‘Change’ (pencil) button

19) Click on ‘New Entries’

20) Enter your Infotype number and short text

21) Here we have to set different Infotype Characteristics as per the requirement. (Better open another session with some standard Infotype’s infotype characteristics screen and use as the reference to fill yours)

22) Save your entries.

23) Now the Infotype is created and ready to use.

24) If you want to change the layout of the Infotype as per your requirement…

25) In the PM01 initial screen…Select ‘Screen’ radio button and give 2000 as the screen name, then click on edit.

26) In the next screen.. Select ‘Layout Editor’ and click ‘Change’.

27) Screen default layout appears…here you can design/modify the screen..change the attributes of the fields..etc.

28) Save and activate. (Don’t forget to ‘Activate at every level)

InfoSets in the HR Application

You can use SAP Query in HR to report on HR data. Queries are maintained as described in Creating Queries. The special features of queries created for HR are described in Maintaining Queries in the Human Resources Application. The maintenance procedure for HR InfoSets differs from the described procedure inasmuch as HR data fields are grouped together in infotypes.

InfoSet management in SAP Query is also used for InfoSet Query. For further information, see Functions for Managing InfoSets.

If you want to create InfoSets for HR, you can use logical databases PNP, PAP, and PCH (see HR Logical Databases). The database you must use to create your InfoSet depends on the component in which the data you want to report on is stored.

The reports you can execute using InfoSets based on logical databases PNP or PCH are similar, but differ in that they can select different objects. The following table describes the connection between the logical database, and the infotypes you can include in an InfoSet. It also provides you with one or two examples of reports that you can execute using the appropriate InfoSets.

Logical database PNP PCH PAP

Selection of Persons Objects from Personnel Planning Applicants

Infotypes that can be included in the InfoSet Infotypes for

• Personnel Administration (0000-0999)

• Time Management (2000-2999)

• Payroll infotypes

• Infotypes for Personnel Planning objects that can be related to persons If the object type is specified:

• Infotypes for the object type

• Infotypes for objects that can be related to the specified object type

If the object type is not specified:

• All infotypes • Infotypes for Recruitment (4000-4999)

• Some infotypes for Personnel Administration (such as 0001 and 0002)

• Customer infotypes

Reporting examples • Selection of all persons who participated in a specific business event, output of prices for reserved business events

• Selection of all persons assigned to a specific personnel area, output of qualifications held by these persons • Selection of all business events held in London in March, output of all persons who participated in these business events

• Selection of all positions assigned to a specific organizational unit, output of all persons assigned to the positions • Selection of all applicants hired last year to work on special projects, output of addresses for the applicants selected

Creating InfoSets

The maintenance procedure for HR InfoSets differs from the procedure described so far in this section inasmuch as HR data fields are grouped together in infotypes. To set up an InfoSet for the HR application, proceed as follows:

1. On the initial screen for maintaining InfoSets, enter a name for the InfoSet and choose Create.

2. On the next screen, enter a name for the InfoSet and select one of the HR logical databases in accordance with your reporting requirements.

Customer infotypes can be created on all HR logical databases. In each individual case, therefore, you must decide which database to select so that you can report on customer infotypes.

This screen enables you to enter an authorization group. All of the queries that are subsequently created using this InfoSet can only be executed by persons who have this authorization group.

3. Choose .

This takes you to the Infotype Selection for InfoSet .

The logical HR database uses the table APPLICANT. You must declare it in the TABLES statement.

At the GET APPLICANT event, the APPLICANT structure contains the data for an applicant number chosen on the basis of selection screen entries.

The APPLICANT-APLNO field contains the applicant number which is selected for processing.

Only the APPLICANT-APLNO field should be read from the work area of the APPLICANT table. The other fields are intended for internal use only.

2.7 Authorization Checks in Reporting (PA-APP)

Generally, authorization checks in reporting do not differ from those in the transactions. Since data access in reporting is always of the read type, the system checks for a read authorization; the authorization group must be R or *.

In some situations, you may want to use a simplified authorization check when running reports. The object RPABAP is required for the check as well as the object RPORGIN; if these authorizations are available, a simpler and faster check is performed.

If the report cannot read certain applicant data due to lack of authorization, data for these persons is not processed at the GET APPLICANT time point. A note appears at the end of the list stating the number of applicants who were skipped due to lack of authorization.

2.8 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.

These two types of logical views are implemented in the projection and join.

 Join

 Projection

 Join and Projection

 Time-Dependent Control Tables

 Generalization of the View

Join

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 Pomp

FROM Pnnnn

BETWEEN PN-BEGDA AND PN-ENDDA.

The partial periods for infotypes Pomp 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 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.

Time-Dependent Control Tables

Infotype data is generally coded as a key (for example, infotype P0006, address type 1 = permanent residence) to allow fast data entry and space-saving storage. When you process infotypes, the texts or attributes of the keys are read from the relevant control tables.

In many control tables, storage of data is time-dependent and therefore assigned a validity period.

In HR, this applies to the following areas:

• Work schedules

• Pay scale structures

• Wage types

• Wage type valuation

• Bank data

• Positions

• Payee codes

When you read the data for an infotype key from time-dependent control tables, you must determine which record is valid in the specified validity period.

If you use a transaction to process an infotype, the system reads the table record which is valid on the start date.

Generalization of the View

You can use the logical view to edit and output data according to user specifications.

The special feature of HR views is the time dependency of the data. Personnel data is almost always related to specific validity periods. A HR view provides data for specific time intervals.

In general terms, a HR view is a logical perspective of interval-dependent internal tables.