Contraction and the PROVIDE command help needed!

[Former Member]

I'm a new ABAP programmer that's been doing some HR-specific work (I've been through the HR350 Programming training course). I've got a pretty good understanding of using the PNPCE LDB as an easy way of obtaining the data I need for a report or interface.

Here's my issue: On this particular request, the users don't want to see people "duplicated" on a report simply because a field they don't consider "major" changes, yielding an additional record in my system-provided Infotype table. They have identified 3 fields (let's just call 'em FIELD1, FIELD2, and FIELD3) as the fields they wish to contract upon. So only if any of these 3 fields change do they wish to see another row on the report.

Here's my code:

PROVIDE FIELD1 FIELD2 FIELD3 from P0001

• from P0008

BETWEEN pn-begda AND pn-endda

WHERE p0008-subty = '0'.

The problem is that ONLY fields FIELD1, FIELD2, and FIELD3 get returned from P0001. I do understand that that's what I'm asking for, so that's what I'm getting. But there are OTHER fields from P0001 that I need to get to display on the report.

What do I do? I'm guessing this has to be a pretty common issue when working with contraction, I just don't know the best method on how to deal with it.

1. One colleague suggested I put in a SELECT to get the rest of the data. I'd really not have to do a database read for every record I process, though.

2. Another suggested that prior to the PROVIDE, I copy the P0001 table to an internal table. Then I go read it for the record that encompasses the begin/end dates of the contracted record. That makes a little more sense to me, because at least I'm going back to a table in memory vs. back out to the physical database.

3. Other options?

I can see this occurring on some future items coming my way, so I'd like to see what some of you HR gurus out there would do in this situation.

Thanks so much! Points will be awarded, as always!

[Former Member]

I'm a new ABAP programmer that's been doing some HR-specific work (I've been through the HR350 Programming training course). I've got a pretty good understanding of using the PNPCE LDB as an easy way of obtaining the data I need for a report or interface.

Here's my issue: On this particular request, the users don't want to see people "duplicated" on a report simply because a field they don't consider "major" changes, yielding an additional record in my system-provided Infotype table. They have identified 3 fields (let's just call 'em FIELD1, FIELD2, and FIELD3) as the fields they wish to contract upon. So only if any of these 3 fields change do they wish to see another row on the report.

Here's my code:

PROVIDE FIELD1 FIELD2 FIELD3 from P0001

• from P0008

BETWEEN pn-begda AND pn-endda

WHERE p0008-subty = '0'.

The problem is that ONLY fields FIELD1, FIELD2, and FIELD3 get returned from P0001. I do understand that that's what I'm asking for, so that's what I'm getting. But there are OTHER fields from P0001 that I need to get to display on the report.

What do I do? I'm guessing this has to be a pretty common issue when working with contraction, I just don't know the best method on how to deal with it.

1. One colleague suggested I put in a SELECT to get the rest of the data. I'd really not have to do a database read for every record I process, though.

2. Another suggested that prior to the PROVIDE, I copy the P0001 table to an internal table. Then I go read it for the record that encompasses the begin/end dates of the contracted record. That makes a little more sense to me, because at least I'm going back to a table in memory vs. back out to the physical database.

3. Other options?

I can see this occurring on some future items coming my way, so I'd like to see what some of you HR gurus out there would do in this situation.

Thanks so much! Points will be awarded, as always!

[vinod_gunaware2]

Logical database

A logical database is a special ABAP/4 program which combines the contents of certain database tables. Using logical databases facilitates the process of reading database tables.

HR Logical Database is PNP

Main Functions of the logical database PNP:

Standard Selection screen

Data Retrieval

Authorization check

To use logical database PNP in your program, specify in your program attributes.

Standard Selection Screen

Date selection

Date selection delimits the time period for which data is evaluated. GET PERNR retrieves all records of the relevant infotypes from the database. When you enter a date selection period, the PROVIDE loop retrieves the infotype records whose validity period overlaps with at least one day of this period.

Person selection

Person selection is the 'true' selection of choosing a group of employees for whom the report is to run.

Sorting Data

· The standard sort sequence lists personnel numbers in ascending order.

· SORT function allows you to sort the report data otherwise. All the sorting fields are from infotype 0001.

Report Class

· You can suppress input fields which are not used on the selection screen by assigning a report class to your program.

· If SAP standard delivered report classes do not satisfy your requirements, you can create your own report class through the IMG.

Data Retrieval from LDB

1. Create data structures for infotypes.

INFOTYPES: 0001, "ORG ASSIGNMENT

0002, "PERSONAL DATA

0008. "BASIC PAY

2. Fill data structures with the infotype records.

Start-of-selection.

GET PERNR.

End-0f-selection.

Read Master Data

Infotype structures (after GET PERNR) are internal tables loaded with data.

The infotype records (selected within the period) are processed sequentially by the PROVIDE - ENDPROVIDE loop.

GET PERNR.

PROVIDE * FROM Pnnnn BETWEEN PN/BEGDA AND PN/ENDDA

If Pnnnn-XXXX = ' '. write:/ Pnnnn-XXXX. endif.

ENDPROVIDE.

Period-Related Data

All infotype records are time stamped.

IT0006 (Address infotype)

01/01/1990 12/31/9999 present

Which record to be read depends on the date selection period specified on the

selection screen. PN/BEGDA PN/ENDDA.

Current Data

IT0006 Address - 01/01/1990 12/31/9999 present

RP-PROVIDE-FROM-LAST retrieves the record which is valid in the data selection period.

For example, pn/begda = '19990931' pn/endda = '99991231'

IT0006 subtype 1 is resident address

RP-PROVIDE-FROM-LAST P0006 1 PN/BEGDA PN/ENDDA.

Process Infotypes

RMAC Modules - RMAC module as referred to Macro, is a special construct of ABAP/4 codes. Normally, the program code of these modules is stored in table 'TRMAC'. The table key combines the program code under a given name. It can also be defined in programs.The RMAC defined in the TRMAC can be used in all Reports. When an RMAC is changed, the report has to be regenerated manually to reflect the change.

Reading Infotypes - by using RMAC (macro) RP-READ-INFOTYPE

REPORT ZHR00001.

INFOTYPE: 0002.

PARAMETERS: PERNR LIKE P0002-PERNR.

RP-READ-INFOTYPE PERNR 0002 P0002 .

PROVIDE * FROM P0002

if ... then ...endif.

ENDPROVIDE.

Changing Infotypes - by using RMAC (macro) RP-READ-INFOTYPE.

· Three steps are involved in changing infotypes:

1. Select the infotype records to be changed;

2. Make the required changes and store the records in an alternative table;

3. Save this table to the database;

The RP-UPDATE macro updates the database. The parameters of this macro are the OLD internal table containing the unchanged records and the NEW internal table containing the changed records. You cannot create or delete data. Only modification is possible.

INFOTYPES: Pnnnn NAME OLD,

Pnnnn NAME NEW.

GET PERNR.

PROVIDE * FROM OLD

WHERE .... = ... "Change old record

*Save old record in alternate table

NEW = OLD.

ENDPROVIDE.

RP-UPDATE OLD NEW. "Update changed record

Infotype with repeat structures

· How to identify repeat structures.

a. On infotype entry screen, data is entered in table form.

IT0005, IT0008, IT0041, etc.

b. In the infotype structure, fields are grouped by the same name followed by sequence number.

P0005-UARnn P0005-UANnn P0005-UBEnn

P0005-UENnn P0005-UABnn

Repeat Structures

· Data is entered on the infotype screen in table format but stored on the database in a linear

structure.

· Each row of the table is stored in the same record on the database.

· When evaluating a repeat structure, you must define the starting point, the increment and the

work area which contains the complete field group definition.

Repeat Structures Evaluation (I)

· To evaluate the repeat structures

a. Define work area.

The work area is a field string. Its structure is identical to that of the field group.

b. Use a DO LOOP to divide the repeat structure into segments and make it available for

processing in the work area, one field group (block) at a time.

Repeat Structures Evaluation(II)

• Define work area

DATA: BEGIN OF VACATION,

UAR LIKE P0005-UAR01, "Leave type

UAN LIKE P0005-UAN01, "Leave entitlement

UBE LIKE P0005-UBE01, "Start date

UEN LIKE P0005-UEN01, "End date

UAB LIKE P0005-UAB01, "Leave accounted

END OF VACATION.

GET PERNR.

RP-PROVIDE-FROM-LAST P0005 SPACE PN/BEGDA PN/ENDDA.

DO 6 TIMES VARYING VACATION

FROM P0005-UAR01 "Starting point

NEXT P0005-UAR02. "Increment

If p0005-xyz then ... endif.

ENDDO.

Processing 'Time Data'.

· Dependence of time data on validity period

· Importing time data

· Processing time data using internal tables

Time Data and Validity Period

· Time data always applies to a specific validity period.

· The validity periods of different types of time data are not always the same as the date selection period specified in the selection screen.

Date selection period |----

-

---

|

Leave |----

-

---

|

· PROVIDE in this case is therefore not used for time infotypes.

Importing Time Data

· GET PERNR reads all time infotypes from the lowest to highest system data, not only those within the date selection period.

· To prevent memory overload, add MODE N to the infotype declaration. This prevents the logical database from importing all data into infotype tables at GET PERNR.

· Use macro RP-READ-ALL-TIME-ITY to fill infotype table.

INFOTYPES: 2001 MODE N.

GET PERNR.

RP-READ-ALL-TIME-ITY PN/BEGDA PN/ENDDA.

LOOP AT P0021.

If P0021-XYZ = ' '. A=B. Endif.

ENDLOOP.

Processing Time Data

· Once data is imported into infotype tables, you can use an internal table to process the interested data.

DATA: BEGIN OF ITAB OCCURS 0,

BUKRS LIKE P0001-BUKRS, "COMPANY

WERKS LIKE P0001-WERKS, "PERSONNEL AREA

AWART LIKE P2001-AWART, "ABS./ATTEND. TYPE

ASWTG LIKE P2001-ASWTG, "ABS./ATTEND. DAYS

END OF ITAB.

GET PERNR.

RP-PROVIDE-FROM-LAST P0001 SAPCE PN/BEGDA PN/ENDDA.

CLEAR ITAB.

ITAB-BUKRS = P0001-BURKS. ITAB-WERKS = P0001-WERKS.

RP-READ-ALL-TIME-ITY PN/BEGDA PN/ENDDA.

LOOP AT P2001.

ITAB-AWART = P2001-AWART. ITAB-ASWTG = P2001-ASWTG.

COLLECT ITAB. (OR: APPEND ITAB.)

ENDLOOP.

Hope this will help

regards

vinod

[suresh_datti]

Hi David,

Instead of the SELECT, I would suggest the use of the function module HR_READ_INFOTYPE. This way, you need not worry about Authorization checks & Coding standards ( at some places they do not let you put a SELECT inside a GET event) etc.

Regards,

Suresh Datti

[Former Member]

Hi,

Just use P0001 as any other Internal table U would use

inside your program.

P0001 will be filled when U call the GET PERNR for the

PERNR

Regards,

GSR.

[Former Member]

Srinivas,

I was thinking I couldn't do that because P0001 would be "overwritten" with the results of my PROVIDE statement. However, looking at this more closely thru debugging, I see that it's the Header Row (and this Header Row business has always kinda thrown me since I started learning ABAP) that has the "joined" record, with the PNBEGDA and PNENDDA dates delimited to match the results of the join. The other two "original" records are still in P0001.

So you're saying to just go ahead and search or read P0001 for the "original" record that has all of the fields before the join/contraction took place, since only the Header Row has the joined/contracted record -- correct?

[Former Member]

Hi Dave,

Yes , U have all the records in P0001.

We need to loop at P0001 or use a macro (if U want the

last or first record in the dates given) to get the

record.

P0001 always has the latest record in the header.

Regards,

Srinivas.

[Former Member]

Thank you, Srinivas. I think that approach makes sense. Can't tell you how much I've learned about contraction as well as Header Records in internal tables today!

Thanks to the others as well -- I assigned helpful advice points to you!