Retroactive Calculation
Hi Everyone,
Iam hiring an employee from the mid of the month suppose 15th of the current month. So the calculation should be pro-rata that is the employee should get the payment only from the joining date but , when iam processing the payroll the wagetype is getting calculated for the whole month and it is not calculating as per attended days, can any one help me ?
Srijit
Hi Patrick,
Again Thanks for your Prompt reply,
No the wage type i have copied is from 008 that is MB10, and the modified wage type is also stored in the 0008 infoype only.......
For Retro calculation do we have to modify any PCR's....any idea.
Srijit
Similar Messages
-
Posting to Accounting: Retroactive Posting after a change in the GL account
Hello all,
i would like to ask you about a problem that we face in a live system throught the integration HR-FI. We have already run live posting to accounting until the end of November. But, the client wants us to change the account of a wage type. We have created a new symbolic account because the new account is an expense account whereas the previous account was a balance sheet account. We have used also the user exit in RPCIPE00 as we have different employee groupings in our system. The problem is that when we run posting to accounting for December and there is retroactive calculation the system debit/credit again the old wage type again without having results in December for this wage type.
Customizing :
01.2010-11.2010 DEBIT : X1(BALANCE SHEET)
CREDIT: Z1
122010-12.9999 DEBIT : X2(EXPENSE ACCOUNT)
CREDIT: Z1
Example:
11.2010 -> Payroll calculation for WT01:100 EUROS. Posting of this WT01: Debit : X1 (100EUROS) Account ,Credit : Z1 Account ((100EUROS)
12.2010 -> Retroactive calculation for november for other wage types. Not WT01. But in the posting to accounting for WT01 there is debit/credit. Note: After 01.12 we have the change in the posting customizing of this WT01.
DEBIT CREDIT
X1 (100EUROS)
Z1 (100EUROS) (100EUROS)
X2 (100EUROS)
How can i stop the retroactive posting that takes place after the change? This wage type WT01 SHOULD NOT be posted in December.
I am looking forward to your feedback.
Thank you in advance.
SissiThank you for your quick response.
I have already delimited Wage Type WT01 and used the new symbolic account:
Customizing :
01.2010-11.2010 DEBIT : X100 Symbolic (BALANCE SHEET)
CREDIT: Z100 Symbolic
12.2010-12.9999 DEBIT : X200 Symbolic(EXPENSE ACCOUNT)
CREDIT: Z100 Symbolic
FI: X100 symbolic Linked to X1 ACCOUNT
X200 symbolic Linked to X2 ACCOUNT(NEW ONE)
Z100 symbolic Linked to Z1 Account
The problem is that after posting for December i have 100 euros as debit in Account X2 (the new account) and 100 euros in the old account X1 as credit. IN Z1 account i have no problem as the result is zeroed. According to the customer, they should not have these amounts in X1,X2 accounts as there is no retro-calculation for this specific WType.
Accounts DEBIT CREDIT
X1 : <-> (100EUROS as CREDIT)
Z1 : (100EUROS as DEBIT) (100EUROS as CREDIT)
X2 : (100EUROS as DEBIT) <->
I hope the schema above will depict how the posting is performed after the change in account of the wage type.
So, you suggest that this cannot be ceased as the system works in this way?
Thank you a lot.
Sissy. -
Hi,
does anyone know if there is any table or transaction that traces what modification or process has motivated a retroactivity calculation of the payroll?.
I'm trying to find what has caused a retroactivity and i'm not being able to find the reason.
Thanks in advance.Hi,
Basically this is the Class which is responsible for Retro calculation - CL_HRPA_RETROCALC
Try with this class. you can debug and know whats going on.. T-code for class is SE24.
//Kothand -
How to discover what caused retroactivity
Hi,
does anyone know if there is any table or transaction that traces what modification or process has motivated a retroactivity calculation of the payroll?.
I'm trying to find what has caused a retroactivity and i'm not being able to find the reason.
Thanks in advance.Hi,
In order to see the infotypes you want to see, you must first flag them to be logged. You can do this by going to the following tables:
V_T585A
V_T585B
V_T585C
These tables will allow you to see teh infotypes you want to see and will allow you to select specific fields to log as well.
Hope this helps.
Suparna -
I have a requirement. I had created 3 wage types sometime in 2011 with effective start date 01/01/2011. They had got assigned to the wrong G/Ls. Now these G/Ls have been replaced with new G/Ls.
what need to do now is the assignment to new G/Ls will be from 01/01/2012 and the payroll that has been run from then till now need to retro back to the new G/Ls.Idealy, you would correct the G/L account associated with these WTs and force retroactive calculation to 2011.01.01 since that would make all the corrections automatically. But you should talk to Finance first since they may have closed their fiscal year, delimited the incorrect G/L account, etc..., and they could possibly re-activate the "wrong G/L" temporarily to allow Payroll to make the corrections and force the retrocalculation (wether to 2011 or 2012).
No matter what is the solution, after you have applied it, you will probably have to block retroactive calculation for the concerned employees (via IT0003). -
hi friends,
right now i'm using transaction PTMW.
the difference btn start & end times is not getting calculated now.if i'm using some FM and getting it done, other functionalities are getting affected.
So, now what i need is -
it wont be triggering infotype 3 anymore than what it should. For example, when an employee has his retroactive calculation set to 20.06.2007, and then an absence is created for the 15th, this will generate that the system will trigger the retro calculation to start on that date.
Plz suggest some solution.
thanks
Praveensorry friends - the mentioned thing is unwanted for me.
Thanks -
Need to develop Payroll monthly deduction report in ABAP-HR
Hi,
If any body know standard report which will suit to my requirement please help me.
Thanks in advance.
Regards,
sureshHi Amit,
Thank you for your prompt reply.
I have got confidence on you that you can help me out as I am new to ABAP-HR.
My actual requirement is below.
Fields/Column Names to be included on report output:
u2022 Personnel Number
u2022 Last Name
u2022 First Name
u2022 SSN
u2022 Cost Center Number/Text
. EE Subgroup
. Adjustment Reason
u2022 Personnel Area
u2022 Effective Date
. Deductions Start/Change Date (This date is always the first of the month for the next payroll deduction/pay period - may require payroll calendar)
u2022 Date of Change (on the individual benefit infotype)
u2022 Name of person who made Change
u2022 Health Plan Type (and Text)
. Medical code
. Flexible Spending Accounts Plan Type/Text (PA0170 u2013 PLTYP u2013 1100, 1150)
. Insurance Plan Text (only) PA0168 u2013 PLTYP u2013 0200, 0250, 0300, 0350)(All of the insurance amounts will be combined, so there is only a need for text and not the type)
. Bi-Weekly Deduction Amount (Pre-tax) (EECST u2013 Employee Cost Pre-tax deduc)
. Bi-Weekly Deduction Amount (Post-tax) (PTCST u2013 Employee Cost Post-tax deduc)
u2022 EE Subgroup
. Imputed Income Amount
. Retroactive Calculation Amount
. Hire Date
. Prev Personnel Num (use u2018PSIDu2019 as column header) (PNALT u2013 IT0032)
u2022 Hire Date
u2022 Prev Personnel Num (use u201CPSID Numberu201D as column header)
Infotypes Within Report Scope
u2022 0000 Actions
u2022 0378 Adjustment Reasons
u2022 0041 Date Specifications
u2022 0170 Flexible Spending Accounts
u2022 0167 Health Plans
u2022 0037 Insurance
u2022 0032 Internal Data
u2022 0001 Organizational Assignment
u2022 0002 Personal Data
Selection screen inclue the select options and parameters as below:
From Date / To Date (range in time analysis) - Select-options
Personnel Number
Country Grouping
Personnel Area - Select-options
Plan Type
Adjustment Reason
I will be waiting for your help.
Regards,
suresh -
Posting to FI/CO error - error in accounting result import
Dear All,
We are facing the following error:
after we created a simulation of posting in PC00_M99_CIPE for one payroll area, we check the created documents and when we check accounts there in the documents there is a message "Error in accounting results import" and then follows the personnel number. And this personnel number is from another payroll area!!!
How can it be? How can a person from another payroll area be included into a posting run for simultaion payroll area??? Why does this error come? And why the posting run status is not "Documents with errors", but is okay - "Documents created".Guys,
I run the simulation for 1 pers. number! And in the documents there are many pernr with wrong import results. And what is even more interestins id that each time I run the simulation, there are different pernr with wromg import results from different payroll areas. By the way, all of them have retroactive calculations. Maybe something wrong with some inner counters??? -
HI FRIENDS,
CAN ANYONE SEND ME THE ABAP-HR MATERIAL .
THAXS AND REGARDS.
HITESHMaybe 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/thread.jspa%3FthreadID%3D9945%26messageID%3D63016
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-organizational-management-745603
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
8) 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 Infotypes 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. (Dont 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.
See also:
Processing All Infotype Records (PA-PAD)
Processing All Infotype Records (PA-APP)
Processing a Specific Infotype Record (PA-PAD)
Processing a Specific Infotype Record (PA-APP)
3 Import/Export Files in HR
The following sections describe the purpose of files PCL1 and PCL2 and explains how to access them.
Files PCL1, PCL2, PCL3 and PCL4
Storing Data in PCLn Files
PCLn Buffer
Cluster Directory Manager
3.1 Files PCL1, PCL2, PCL3 and PCL4
Which information is stored in the files?
File PCL1 is the basis for the HR work area data. It contains information from the time data recording, for example, incentive wage time tickets or infotype supplement texts.
File PCL2 contains derived information, for example, payroll results. It also contains all generated payroll schemas.
File PCL3 contains applicant data.
File PCL4 contains the change documents for HR master data and recruitment.
The structure of PCLn files corresponds to that of the INDX file which you may be familiar with from other applications. The structure of all PCLn files (n = 1, 2, 3, and 4) is identical.
Structure of Files
Like in almost all SAP files, the key element with the highest priority is the client; data within a client is grouped according to basic relations (field PCLn-RELID).
The type of basic relation is known as a cluster and characterizes the stored data according to the type, for example, cluster RX contains the payroll result for country X (from table T500L) and cluster TE contains the trip costs data.
Depending on the cluster, the structure of PCLn-SRTFD is defined in a field string xx-KEY, which is defined in an include RPCnxxy0.
Naming conventions
n = 1, 2, 3, or 4 (for PCL1, PCL2, PCL3, or PCL4)
xx = for the cluster
y = 0 for international clusters
y = country grouping according to T500L for national clusters
The personnel number is usually the first component of xx-KEY.
Importing and Exporting Data
The import/export files PCLn are managed with the ABAP/4® commands IMPORT and EXPORT . These commands store objects such as fields, field strings, or internal tables on the database, or read these from the database. Data is read from and written to the database using a unique key( xx-Key).
Please note that the RMAC macros RP-IMP-Cn-xx and RP-EXP-Cn-xx are provided for importing and exporting data. Only these macros should be used.
See also Macro Modules
3.2 Storing Data in PCLn Files
Data from the different HR application areas is stored in data clusters in PCLn files (n = 1, 2, 3, or 4).
This collection of data objects can consist of:
Fields used within reports
Field strings
Internal tables
The structure of the PCLn files provides a framework for the individual application areas.
Each application area must have a two-character cluster name (relation ID). It must also have a key structure; 40 bytes of the SRTFD field are available for this structure.
When a record is exported to the PCLn file, the cluster ID is written to the RELID field and the key value to the SRTFD field.
Naming convention for includes when defining clusters:
RPCnxxy0 n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country indicator
Description of Cluster Data using Cluster RX as an Example
The data definition is stored in the include RPC2RX00 in accordance with the above naming conventions.
Structure of cluster key:
Data: BEGIN OF RX-KEY.
INCLUDE STRUCTURE PC200.
DATA: END OF RX-KEY.
The DDIC structure PC200 contains the fields PERNR (personnel number) and SEQNO (sequential number).
The data definition of the cluster also contains other internal tables.
For a list of available data clusters, refer to the domain description in the Data Dictionary.
xx Key
The xx key name is dependent on the cluster.
The RX KEY is used for all Rx and Xx clusters. In all other cases, the name of the xx key corresponds to that of the cluster.
Cluster xx Key
RA RX-KEY
B1 B1-KEY
G3 G3-KEY
XA RX-KEY
3.3 PCLn Buffer
To keep the number of database accesses to a minimum, import and export data is stored in the main memory buffer. Buffer management routines ensure that exported data can be stored in the PCLn files.
The following two examples illustrate which problems can occur without a buffer.
Retroactive accounting of payroll results
Starting payroll in the test mode
Retroactive Accounting of Payroll Results
In February 1998, a retroactive accounting run is executed for January.
FOR PERIOD 199801 IN PERIOD 199802
The payroll results for January are recalculated and then written directly to the database.
Result:
The database now contains the results of the following payroll periods.
FOR-PERIOD 199801 IN-PERIOD 199802
FOR-PERIOD 199801 IN-PERIOD 199801
Payroll is then run for February.
FOR-PERIOD 199802 IN-PERIOD 199802
If problems should arise during the payroll run for this period, the February record is not stored on the database.
Result:
The current January record on the database is:
FOR-PERIOD 199801 IN-PERIOD 199802
This problem does not arise if you use the buffer since all data of a transaction is always updated collectively. In the above example, the recalculated January result would be stored in the buffer and, if the payroll run for February were terminated prematurely, the database would not be updated.
The current January record on the database would thus be:
FOR-PERIOD 199801 IN-PERIOD 199802
Starting Payroll in the Test Mode
In a test run, the database is not updated. Since the payroll results from the previous period are used as the basis for calculating the results of the following period, the results of the actual payroll run would differ from those of the test run, if this test run were executed over several periods.
The use of the buffer enables trouble-free access to the required results for the previous period.
What is required for exporting/importing data to/from the PCLn files using the buffer?
 The following includes contain the data definition for the buffer. They must be included in the report that writes the data to or reads the data from the database.
RPPPXD00
RPPPXD10
 Include RPPPXD10 must be in the common part BUFFER .
Include RPPPXM00, which contains the buffer management routines, is also required.
The macros for importing and exporting data must comply with the following naming convention:
Naming Convention for EXPORT/ IMPORT Macros:
RP-aaa-Cn-xy
where aaa = IMP / EXP, n=1 for PCL1, 2 for PCL2, 3 for PCL3, 4 or PCL4
and xy = cluster name.
This guarantees consistency between the export and import of data and also ensures that all exported objects are imported again.
Export Using the Data Buffer
When macros are used for exporting, records are written to a main memory buffer and not directly to the database. When the program run has been completed, the records in the buffer are stored in the appropriate PCLn database.
Import Using the Data Buffer
When the macros are used to import data, the data records are not read directly from file PCLn. Instead, the system checks the buffer directory to see whether the main memory already contains a record with the same key. If this is not the case, the record is read from PCLn to the buffer and then retrieved from the buffer for the report.
If the import is successful, the return code RP-IMP-xy-SUBRC = 0 is set. When data is read from the buffer, the system carries out a check for cluster authorization. Standard import programs follow the naming convention RPCLSTxy (xy = cluster name).
 report rpttcdmg.
tables:
pernr,
pcl1,
pcl2.
include rpppxd00. "buffer definitions
data: begin of common part 'BUFFER'.
include rpppxd10. "PCLx buffer
data: end of common part.
data: begin of common part 'CLUSTER_DIRECTORY'.
include rpc2cd00. " "cluster directory definitions
data: end of common part.
include rpc2rdd0.
get pernr.
rp-init-buffer. "reset buffer
cd-key-pernr = pernr-pernr.
rp-imp-c2-cd. "read cluster CD from
buffer/DB
perform cd_manager using ... .
alternative: call function rp_evaluation_periods...
rx-key-pernr = pernr-pernr.
rx-key-seqno = rgdir-seqnr.
rp-imp-c2-rd. "read cluster RD from
buffer/DB
rp-exp-c2-rd. "update cluster RD in buffer
perform prepare_update using 'V'. "update database (DB)
Subroutines CD manager and Cluster buffer
include rpcmgr00. "Cluster Directory Manager
include rpppxm00. "module pcl1(2)-buffer
3.4 Cluster Directory
Finding Payroll Results for a Specific Query
Payroll results are stored in cluster Rx of the PCL2.
The cluster key is non-mnemonic. It contains the PERNR (personnel number) and SEQNO (sequential number) fields.
The internal table RGDIR contains a directory entry for each payroll result. This entry is a sequential number (RGDIR-SEQNR) which uniquely identifies the payroll result.
Payroll results can only be imported if the payroll cluster key contains the personnel number and sequential number.
Before you can import a payroll record, you must select the entry in the RGDIR on the basis of existing data such as for-period, for-payroll area, for-payroll category, in-period, in-payroll area, in-payroll category, and so on, in order to determine the sequential number.
You will probably always have the same queries when importing payroll records. For example, "Which payroll results (original and retroactively accounted records) were written for a specific payroll run (defined by IN payroll category, IN payroll area, IN period)"?
There are standard modules that can be used. It is advantageous to use the standard modules rather than self-programmed solutions because no program modifications will be required if the payroll directory changes. The modules are described in the following section:
Function Modules for Selecting Payroll Results
3.5 Function Modules for Selecting Payroll Results
The employees payroll directory is always transferred to the function modules using the table RGDIR.
The modules then transfer the payroll records which satisfy the specified selection criteria using a table whose type corresponds to that of the RGDIR but which has a different name. The selection parameters differ according to the function of the module. For more information, read the module documentation.
All module names begin with CD_.
Function Module: CD_EVALUATION_PERIODS
Function Module: CD_READ_PREVIOUS
Function Module: CD_READ_PREVIOUS_ORIGINAL
Other Modules for the Payroll Cluster
Sample Report
Function Module: CD_EVALUATION_PERIODS
This module transfers the payroll results to a payroll run as A records (current). It also transfers the accompanying P records (previous).
This is the module most frequently used in evaluation programs.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID INPTY INPID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96 B 0
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 01.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 01.01.96 02.15.96
The following parameters are transferred:
- BONUS_DATE = '00000000'
- INPER_MODIF = '02'
- INPER = '199803'
- PAYTY = ' '
- PAYID = ' '
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY INPTY INPID SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
Explanation of individual fields
Function Module: CD_READ_PREVIOUS
This module transfers a previous payroll record for a payroll record; this is the newest record for the payroll period (or daily payroll run) which was written before the transferred payroll record and contains the same FOR data as the transferring record.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00007'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
Explanation of individual fields
Function Module: CD_READ_PREVIOUS_ORIGINAL
This module reads the previous original payroll result.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IIPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.3196 P
Explanation of individual fields
3.6 Other Modules for the Payroll Cluster
Modules which derive information from the payroll cluster are available in addition to the modules for payroll result selection.
1. CD_RETROCALC_PERIOD
This module differentiates between original payroll records and retroactive accounting records.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
- CALCD = ' '
Explanation of individual fields
2. CD_PAYROLL_UNTIL
This module reads the RGDIR for the date up to which the regular payroll run was executed for an employee.
3. CD_HIGHEST_PAYDT
This module reads the most recent check date for an employee from the RGDIR.
4. CD_GET_INFO
This module provides information (most recent check date, accounted to date) for a particular personnel number.
3.7 Explanation of Individual Fields
For-Information
The FPPER, FPBEG, FPEND, BONDT, PAYTY, PAYID, ABKRS, PERMO, PAYDT, JUPER fields contain information on the period for which payroll is run.
In-Information
The INPER, IPEND, INPTY, INPID, IABKRS, IPERM fields contain information on the period in which payroll is run.
SEQNR
The field is used as a key to uniquely identify the payroll record.
This field also defines the sequence of payroll results (history).
Control Indicator (SRTZA)
Control indicator Meaning
a Current
p Previous
o Old
 For more information, see the online documentation for the individual function modules.
3.8 Sample Report
REPORT RPTTMWBS.
DATA: RGDIR LIKE PC261 OCCURS 0 WITH HEADER LINE.
DATA: EVPDIR LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: PREVIOUS_RESULTS LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: CALCD TYPE C.
DATA: IN_ENTRY LIKE PC261.
DATA: OUT_ENTRY LIKE PC261.
INCLUDE RPCCCD09.
CALL FUNCTION 'CU_READ_RGDIR'
EXPORTING
PERSNR = '00021218'
TABLES IN_RGDIR = RGDIR
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Read RGDIR
CALL FUNCTION 'CD_EVALUATION_PERIODS'
EXPORTING
BONUS_DATE = '00000000'
INPER_MODIF = '02'
INPER = '199603'
PAY_TYPE = CD_C-REGULAR
PAY_IDENT = ' '
TABLES
RGDIR = RGDIR
EVPDIR = EVPDIR
IABKRS =
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
output:
00006
00007
00008
Read regular payroll results for January
A results (original result plus retroactive calculations)
and P results
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
Only current results (00007 and 00008)
CALL FUNCTION 'CD_RETROCALC_PERIOD'
EXPORTING
ENTRY = EVPDIR
IMPORTING
CALCD = CALCD
EXCEPTIONS
OTHERS = 1.
Determine, whether original result
CHECK CALCD = ' '.
Special processing: Only the original period
March is processed (seqnr 00008).
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS_ORIGINAL'
EXPORTING
IN_RECORD = IN_ENTRY
IMPORTING
OUT_RECORD = OUT_ENTRY
TABLES
RGDIR = RGDIR
EXCEPTIONS
OTHERS = 1.
out_entry now contains the previous results
Input 00008 ----> Output 00006
ENDLOOP.
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS'
EXPORTING
IN_RECORD = IN_ENTRY
TABLES
RGDIR = RGDIR
OUT_RGDIR = PREVIOUS_RESULTS
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Input 00007 ---> 00006
Input 00008 ---> no record found
Output structure is a table, since there can be
several previous results: for example, if legal person
changes, and is retroactively deleted
ENDLOOP
4 Specific Commands
The following sections describe the different specific commands in HR.
Function modules in HR
Macro modules
4.1 Function Modules in HR
Function modules are program modules which have a defined interface and allow type testing of parameters.
They are managed with transaction SE37 and combined to function groups according to relevant criteria. You can access this transaction under Tools  ABAP Workbench  Function Builder.
The HR function groups use the naming convention RPxx or HRxx where xx is an identifier of your choice.
You can use the SHOW FUNCTION * editor command to branch from report processing to function module display.
4.2 Macro Modules
Definition
An module that can be called within an ABAP program.
Use
Like subprograms and function modules, macro modules are a means of presenting programs in modular form. Macro modules (macros) are used often in the Human Resources application component (HR).
Defining and Calling Modules
Two options are provided:
Macros can be defined in reports or includes using the ABAP command DEFINE. A macro can be used within a report or within an include. If a macro is used in a report, and the macro is defined in an include with the DEFINE command, the include must be integrated.
 Macros have the following advantages:
If a macro is changed, each report using this macro is automatically regenerated when it is executed.
Macros can also be defined as RMAC macros. The source code of these modules is stored in the function section of the control table TRMAC (Macros in ABAP Programs). The coding is grouped under a specific name in the table key.
According to conventions, the first two letters of the name must stand for the application. The rest of the name is freely definable.
 Customer-specific RMAC modules should begin with a special character.
The macros defined in the control table TRMAC can be used by all reports.
 When you change a RMAC macro in the table TRMAC, the reports that use this macro are not regenerated automatically. You must regenerate them manually.
The following section includes a list of programming utilities for the logical databases PNP and PAP.
5 Utilities in HR
The following utilities are available.
General Utilities
Report Meaning
RPUACG00 Code generation / authorization check
RPUAUD00 Infotype auditing
Programming Utilities
Report Meaning
RPINCL10 String search in reports
Cluster Utilities
Report Meaning
RPCLSTyy Display cluster for PCLx (yy = RELID)
RPUPxD00 Delete cluster for PCLx (individual data records)
RPUPxD10 Delete cluster for PCLx (several data records)
6 References:
Different parts of the document has been prepared with the help of articles available on Internet
Following websites are referred :
a). http://help.sap.com
b). http://sapfans.com
c). http://www.sap-basis-abap.com/saphr.htm -
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 GalindoMaybe 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/thread.jspa%3FthreadID%3D9945%26messageID%3D63016
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-organizational-management-745603
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
8) 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 Infotypes 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. (Dont 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.
See also:
Processing All Infotype Records (PA-PAD)
Processing All Infotype Records (PA-APP)
Processing a Specific Infotype Record (PA-PAD)
Processing a Specific Infotype Record (PA-APP)
3 Import/Export Files in HR
The following sections describe the purpose of files PCL1 and PCL2 and explains how to access them.
Files PCL1, PCL2, PCL3 and PCL4
Storing Data in PCLn Files
PCLn Buffer
Cluster Directory Manager
3.1 Files PCL1, PCL2, PCL3 and PCL4
Which information is stored in the files?
File PCL1 is the basis for the HR work area data. It contains information from the time data recording, for example, incentive wage time tickets or infotype supplement texts.
File PCL2 contains derived information, for example, payroll results. It also contains all generated payroll schemas.
File PCL3 contains applicant data.
File PCL4 contains the change documents for HR master data and recruitment.
The structure of PCLn files corresponds to that of the INDX file which you may be familiar with from other applications. The structure of all PCLn files (n = 1, 2, 3, and 4) is identical.
Structure of Files
Like in almost all SAP files, the key element with the highest priority is the client; data within a client is grouped according to basic relations (field PCLn-RELID).
The type of basic relation is known as a cluster and characterizes the stored data according to the type, for example, cluster RX contains the payroll result for country X (from table T500L) and cluster TE contains the trip costs data.
Depending on the cluster, the structure of PCLn-SRTFD is defined in a field string xx-KEY, which is defined in an include RPCnxxy0.
Naming conventions
n = 1, 2, 3, or 4 (for PCL1, PCL2, PCL3, or PCL4)
xx = for the cluster
y = 0 for international clusters
y = country grouping according to T500L for national clusters
The personnel number is usually the first component of xx-KEY.
Importing and Exporting Data
The import/export files PCLn are managed with the ABAP/4® commands IMPORT and EXPORT . These commands store objects such as fields, field strings, or internal tables on the database, or read these from the database. Data is read from and written to the database using a unique key( xx-Key).
Please note that the RMAC macros RP-IMP-Cn-xx and RP-EXP-Cn-xx are provided for importing and exporting data. Only these macros should be used.
See also Macro Modules
3.2 Storing Data in PCLn Files
Data from the different HR application areas is stored in data clusters in PCLn files (n = 1, 2, 3, or 4).
This collection of data objects can consist of:
Fields used within reports
Field strings
Internal tables
The structure of the PCLn files provides a framework for the individual application areas.
Each application area must have a two-character cluster name (relation ID). It must also have a key structure; 40 bytes of the SRTFD field are available for this structure.
When a record is exported to the PCLn file, the cluster ID is written to the RELID field and the key value to the SRTFD field.
Naming convention for includes when defining clusters:
RPCnxxy0 n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country indicator
Description of Cluster Data using Cluster RX as an Example
The data definition is stored in the include RPC2RX00 in accordance with the above naming conventions.
Structure of cluster key:
Data: BEGIN OF RX-KEY.
INCLUDE STRUCTURE PC200.
DATA: END OF RX-KEY.
The DDIC structure PC200 contains the fields PERNR (personnel number) and SEQNO (sequential number).
The data definition of the cluster also contains other internal tables.
For a list of available data clusters, refer to the domain description in the Data Dictionary.
xx Key
The xx key name is dependent on the cluster.
The RX KEY is used for all Rx and Xx clusters. In all other cases, the name of the xx key corresponds to that of the cluster.
Cluster xx Key
RA RX-KEY
B1 B1-KEY
G3 G3-KEY
XA RX-KEY
3.3 PCLn Buffer
To keep the number of database accesses to a minimum, import and export data is stored in the main memory buffer. Buffer management routines ensure that exported data can be stored in the PCLn files.
The following two examples illustrate which problems can occur without a buffer.
Retroactive accounting of payroll results
Starting payroll in the test mode
Retroactive Accounting of Payroll Results
In February 1998, a retroactive accounting run is executed for January.
FOR PERIOD 199801 IN PERIOD 199802
The payroll results for January are recalculated and then written directly to the database.
Result:
The database now contains the results of the following payroll periods.
FOR-PERIOD 199801 IN-PERIOD 199802
FOR-PERIOD 199801 IN-PERIOD 199801
Payroll is then run for February.
FOR-PERIOD 199802 IN-PERIOD 199802
If problems should arise during the payroll run for this period, the February record is not stored on the database.
Result:
The current January record on the database is:
FOR-PERIOD 199801 IN-PERIOD 199802
This problem does not arise if you use the buffer since all data of a transaction is always updated collectively. In the above example, the recalculated January result would be stored in the buffer and, if the payroll run for February were terminated prematurely, the database would not be updated.
The current January record on the database would thus be:
FOR-PERIOD 199801 IN-PERIOD 199802
Starting Payroll in the Test Mode
In a test run, the database is not updated. Since the payroll results from the previous period are used as the basis for calculating the results of the following period, the results of the actual payroll run would differ from those of the test run, if this test run were executed over several periods.
The use of the buffer enables trouble-free access to the required results for the previous period.
What is required for exporting/importing data to/from the PCLn files using the buffer?
 The following includes contain the data definition for the buffer. They must be included in the report that writes the data to or reads the data from the database.
RPPPXD00
RPPPXD10
 Include RPPPXD10 must be in the common part BUFFER .
Include RPPPXM00, which contains the buffer management routines, is also required.
The macros for importing and exporting data must comply with the following naming convention:
Naming Convention for EXPORT/ IMPORT Macros:
RP-aaa-Cn-xy
where aaa = IMP / EXP, n=1 for PCL1, 2 for PCL2, 3 for PCL3, 4 or PCL4
and xy = cluster name.
This guarantees consistency between the export and import of data and also ensures that all exported objects are imported again.
Export Using the Data Buffer
When macros are used for exporting, records are written to a main memory buffer and not directly to the database. When the program run has been completed, the records in the buffer are stored in the appropriate PCLn database.
Import Using the Data Buffer
When the macros are used to import data, the data records are not read directly from file PCLn. Instead, the system checks the buffer directory to see whether the main memory already contains a record with the same key. If this is not the case, the record is read from PCLn to the buffer and then retrieved from the buffer for the report.
If the import is successful, the return code RP-IMP-xy-SUBRC = 0 is set. When data is read from the buffer, the system carries out a check for cluster authorization. Standard import programs follow the naming convention RPCLSTxy (xy = cluster name).
 report rpttcdmg.
tables:
pernr,
pcl1,
pcl2.
include rpppxd00. "buffer definitions
data: begin of common part 'BUFFER'.
include rpppxd10. "PCLx buffer
data: end of common part.
data: begin of common part 'CLUSTER_DIRECTORY'.
include rpc2cd00. " "cluster directory definitions
data: end of common part.
include rpc2rdd0.
get pernr.
rp-init-buffer. "reset buffer
cd-key-pernr = pernr-pernr.
rp-imp-c2-cd. "read cluster CD from
buffer/DB
perform cd_manager using ... .
alternative: call function rp_evaluation_periods...
rx-key-pernr = pernr-pernr.
rx-key-seqno = rgdir-seqnr.
rp-imp-c2-rd. "read cluster RD from
buffer/DB
rp-exp-c2-rd. "update cluster RD in buffer
perform prepare_update using 'V'. "update database (DB)
Subroutines CD manager and Cluster buffer
include rpcmgr00. "Cluster Directory Manager
include rpppxm00. "module pcl1(2)-buffer
3.4 Cluster Directory
Finding Payroll Results for a Specific Query
Payroll results are stored in cluster Rx of the PCL2.
The cluster key is non-mnemonic. It contains the PERNR (personnel number) and SEQNO (sequential number) fields.
The internal table RGDIR contains a directory entry for each payroll result. This entry is a sequential number (RGDIR-SEQNR) which uniquely identifies the payroll result.
Payroll results can only be imported if the payroll cluster key contains the personnel number and sequential number.
Before you can import a payroll record, you must select the entry in the RGDIR on the basis of existing data such as for-period, for-payroll area, for-payroll category, in-period, in-payroll area, in-payroll category, and so on, in order to determine the sequential number.
You will probably always have the same queries when importing payroll records. For example, "Which payroll results (original and retroactively accounted records) were written for a specific payroll run (defined by IN payroll category, IN payroll area, IN period)"?
There are standard modules that can be used. It is advantageous to use the standard modules rather than self-programmed solutions because no program modifications will be required if the payroll directory changes. The modules are described in the following section:
Function Modules for Selecting Payroll Results
3.5 Function Modules for Selecting Payroll Results
The employees payroll directory is always transferred to the function modules using the table RGDIR.
The modules then transfer the payroll records which satisfy the specified selection criteria using a table whose type corresponds to that of the RGDIR but which has a different name. The selection parameters differ according to the function of the module. For more information, read the module documentation.
All module names begin with CD_.
Function Module: CD_EVALUATION_PERIODS
Function Module: CD_READ_PREVIOUS
Function Module: CD_READ_PREVIOUS_ORIGINAL
Other Modules for the Payroll Cluster
Sample Report
Function Module: CD_EVALUATION_PERIODS
This module transfers the payroll results to a payroll run as A records (current). It also transfers the accompanying P records (previous).
This is the module most frequently used in evaluation programs.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID INPTY INPID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96 B 0
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 01.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 01.01.96 02.15.96
The following parameters are transferred:
- BONUS_DATE = '00000000'
- INPER_MODIF = '02'
- INPER = '199803'
- PAYTY = ' '
- PAYID = ' '
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY INPTY INPID SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96 A
Explanation of individual fields
Function Module: CD_READ_PREVIOUS
This module transfers a previous payroll record for a payroll record; this is the newest record for the payroll period (or daily payroll run) which was written before the transferred payroll record and contains the same FOR data as the transferring record.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00007'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96 P
Explanation of individual fields
Function Module: CD_READ_PREVIOUS_ORIGINAL
This module reads the previous original payroll result.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IIPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY SRTZA
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.3196 P
Explanation of individual fields
3.6 Other Modules for the Payroll Cluster
Modules which derive information from the payroll cluster are available in addition to the modules for payroll result selection.
1. CD_RETROCALC_PERIOD
This module differentiates between original payroll records and retroactive accounting records.
Table contents before the function module is accessed:
SEQNR FPPER FPBEG FPEND INPER IPBEG IPEND BONDT PAYTY PAYID
00001 01.1996 01.01.96 01.15.96 01.1996 01.01.96 01.15.96
00002 01.1996 01.01.96 01.15.96 01.16.96 01.16.96
00003 01.16.96 01.16.96 01.16.96 01.16.96 01.16.96 B 0
00004 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 0
00005 01.17.96 01.17.96 01.17.96 01.17.96 01.17.96 A 1
00006 02.1996 01.16.96 01.31.96 02.1996 01.16.96 01.31.96
00007 02.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
00008 03.1996 01.16.96 01.31.96 03.1996 02.01.96 02.15.96
The following parameters are transferred:
- Record with SEQNR '00008'
Result:
- CALCD = ' '
Explanation of individual fields
2. CD_PAYROLL_UNTIL
This module reads the RGDIR for the date up to which the regular payroll run was executed for an employee.
3. CD_HIGHEST_PAYDT
This module reads the most recent check date for an employee from the RGDIR.
4. CD_GET_INFO
This module provides information (most recent check date, accounted to date) for a particular personnel number.
3.7 Explanation of Individual Fields
For-Information
The FPPER, FPBEG, FPEND, BONDT, PAYTY, PAYID, ABKRS, PERMO, PAYDT, JUPER fields contain information on the period for which payroll is run.
In-Information
The INPER, IPEND, INPTY, INPID, IABKRS, IPERM fields contain information on the period in which payroll is run.
SEQNR
The field is used as a key to uniquely identify the payroll record.
This field also defines the sequence of payroll results (history).
Control Indicator (SRTZA)
Control indicator Meaning
a Current
p Previous
o Old
 For more information, see the online documentation for the individual function modules.
3.8 Sample Report
REPORT RPTTMWBS.
DATA: RGDIR LIKE PC261 OCCURS 0 WITH HEADER LINE.
DATA: EVPDIR LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: PREVIOUS_RESULTS LIKE RGDIR OCCURS 0 WITH HEADER LINE.
DATA: CALCD TYPE C.
DATA: IN_ENTRY LIKE PC261.
DATA: OUT_ENTRY LIKE PC261.
INCLUDE RPCCCD09.
CALL FUNCTION 'CU_READ_RGDIR'
EXPORTING
PERSNR = '00021218'
TABLES IN_RGDIR = RGDIR
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Read RGDIR
CALL FUNCTION 'CD_EVALUATION_PERIODS'
EXPORTING
BONUS_DATE = '00000000'
INPER_MODIF = '02'
INPER = '199603'
PAY_TYPE = CD_C-REGULAR
PAY_IDENT = ' '
TABLES
RGDIR = RGDIR
EVPDIR = EVPDIR
IABKRS =
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
output:
00006
00007
00008
Read regular payroll results for January
A results (original result plus retroactive calculations)
and P results
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
Only current results (00007 and 00008)
CALL FUNCTION 'CD_RETROCALC_PERIOD'
EXPORTING
ENTRY = EVPDIR
IMPORTING
CALCD = CALCD
EXCEPTIONS
OTHERS = 1.
Determine, whether original result
CHECK CALCD = ' '.
Special processing: Only the original period
March is processed (seqnr 00008).
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS_ORIGINAL'
EXPORTING
IN_RECORD = IN_ENTRY
IMPORTING
OUT_RECORD = OUT_ENTRY
TABLES
RGDIR = RGDIR
EXCEPTIONS
OTHERS = 1.
out_entry now contains the previous results
Input 00008 ----> Output 00006
ENDLOOP.
LOOP AT EVPDIR WHERE SRTZA = CD_C-ACTUAL.
IN_ENTRY = EVPDIR.
CALL FUNCTION 'CD_READ_PREVIOUS'
EXPORTING
IN_RECORD = IN_ENTRY
TABLES
RGDIR = RGDIR
OUT_RGDIR = PREVIOUS_RESULTS
EXCEPTIONS
NO_RECORD_FOUND = 1
OTHERS = 2.
Input 00007 ---> 00006
Input 00008 ---> no record found
Output structure is a table, since there can be
several previous results: for example, if legal person
changes, and is retroactively deleted
ENDLOOP
4 Specific Commands
The following sections describe the different specific commands in HR.
Function modules in HR
Macro modules
4.1 Function Modules in HR
Function modules are program modules which have a defined interface and allow type testing of parameters.
They are managed with transaction SE37 and combined to function groups according to relevant criteria. You can access this transaction under Tools  ABAP Workbench  Function Builder.
The HR function groups use the naming convention RPxx or HRxx where xx is an identifier of your choice.
You can use the SHOW FUNCTION * editor command to branch from report processing to function module display.
4.2 Macro Modules
Definition
An module that can be called within an ABAP program.
Use
Like subprograms and function modules, macro modules are a means of presenting programs in modular form. Macro modules (macros) are used often in the Human Resources application component (HR).
Defining and Calling Modules
Two options are provided:
Macros can be defined in reports or includes using the ABAP command DEFINE. A macro can be used within a report or within an include. If a macro is used in a report, and the macro is defined in an include with the DEFINE command, the include must be integrated.
 Macros have the following advantages:
If a macro is changed, each report using this macro is automatically regenerated when it is executed.
Macros can also be defined as RMAC macros. The source code of these modules is stored in the function section of the control table TRMAC (Macros in ABAP Programs). The coding is grouped under a specific name in the table key.
According to conventions, the first two letters of the name must stand for the application. The rest of the name is freely definable.
 Customer-specific RMAC modules should begin with a special character.
The macros defined in the control table TRMAC can be used by all reports.
 When you change a RMAC macro in the table TRMAC, the reports that use this macro are not regenerated automatically. You must regenerate them manually.
The following section includes a list of programming utilities for the logical databases PNP and PAP.
5 Utilities in HR
The following utilities are available.
General Utilities
Report Meaning
RPUACG00 Code generation / authorization check
RPUAUD00 Infotype auditing
Programming Utilities
Report Meaning
RPINCL10 String search in reports
Cluster Utilities
Report Meaning
RPCLSTyy Display cluster for PCLx (yy = RELID)
RPUPxD00 Delete cluster for PCLx (individual data records)
RPUPxD10 Delete cluster for PCLx (several data records)
6 References:
Different parts of the document has been prepared with the help of articles available on Internet
Following websites are referred :
a). http://help.sap.com
b). http://sapfans.com
c). http://www.sap-basis-abap.com/saphr.htm
HR:
HR deals with the INFOTYPES which are similar to Tables in General ABAP.
There are different ways of fetching data from these infotypes.
There are different areas in HR LIKE Personal Admn, Orgn Management, Benefits, Time amangement, Event Management, Payroll etc
Infotypes for these areas are different from one another area.
storing of records data in each type of area is different
LDBS like PNP are used in HR programing.
Instead of Select.. we use some ROUTINES and PROVIDE..ENDPROVIDE.. etc
and in the case of Pay roll we use Clusters and we Import and Export them for data fetching.
On the whole Normal ABAP is different from HR abap.
For Personal Admn the Infotypes start with PA0000 to PA1999
Time Related Infotypes start with PA2000 to PA2999.
Orgn related Infotypes start with HRP1000 to HRP1999.
All custom developed infotypes stsrat with PA9000 onwards.
In payroll processing we use Clusters like PCL1,2,3 and 4.
Instead of Select query we use PROVIDE and ENDPROVIDE..
You have to assign a Logical Database in the attributes PNP.
Go through the SAp doc for HR programming and start doing.
http://www.sapdevelopment.co.uk/hr/hrhome.htm
See:
http://help.sap.com/saphelp_46c/helpdata/en/4f/d5268a575e11d189270000e8322f96/content.htm
sites regarding hr-abap:
http://www.sapdevelopment.co.uk/hr/hrhome.htm
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PAPA/PAPA.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PAPD/PAPD.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PYINT/PYINT_BASICS.pdf
http://www.atomhr.com/training/Technical_Topics_in_HR.htm
http://www.planetsap.com/hr_abap_main_page.htm
You can see some Standard Program examples in this one ...
http://www.sapdevelopment.co.uk/programs/programshr.htm
http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci1030179,00.html?Offer=SAlgwn12604#Certification
http://www.erpgenie.com/faq/hr.htm.
http://www.planetsap.com/hr_abap_main_page.htm
http://www.sapbrain.com/TUTORIALS/FUNCTIONAL/HR_tutorial.html
These are the FAQ's that might helps you as well.
http://www.sap-img.com/human/hr-faq.htm
http://www.sapgenie.com/faq/hr.htm
http://www.planetsap.com/hr_abap_main_page.htm
http://www.atomhr.com/library_full.htm
HR Long texts Upload
Look at the below link
sample code
START-OF-SELECTION.
GET pernr.
rp_provide_from_frst p0000 space pn-begda pn-endda.
if pnp-sw-found EQ '1'.
READ TABLE p0001 WITH KEY pernr = p0000-pernr.
if sy-subrc = 0.
write : p0001-plans. " earliest.
endif.
endif.
rp_provide_from_last p0014 space pn-begda pn-endda.
if pnp-sw-found EQ '1'.
READ TABLE p0014 WITH KEY pernr = p0000-pernr.
if sy-subrc = 0.
write : p0014-LGART. .
endif.
endif.
check out the following links
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PYINT/PYINT_DATAEX.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CAARCHR/CAARCHR.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PAXX/PAXX.pdf
general links..
http://www.sap-img.com/abap.htm
http://help.sap.com/saphelp_46c/helpdata/en/fc/eb2d67358411d1829f0000e829fbfe/content.htm
http://www.geocities.com/victorav15/sapr3/abap.html
http://www.henrikfrank.dk/abapexamples/SapScript/sapscript.htm
http://abap4.tripod.com/Other_Useful_Tips.html
http://help.sap.com/saphelp_45b/helpdata/en/cf/21ee2b446011d189700000e8322d00/content.htm
http://www.sap-basis-abap.com/sapmm.htm
http://sap.ittoolbox.com/nav/t.asp?t=303&p=448&h1=303&h2=322&h3=448
http://sapfans.com/
http://cma.zdnet.com/book/abap/ch03/ch03.htm
http://help.sap.com/saphelp_40b/helpdata/en/4f/991f82446d11d189700000e8322d00/applet.htm
http://sappoint.com/abap/
http://www.henrikfrank.dk/abapuk.html
http://www.sts.tu-harburg.de/teaching/sap_r3/ABAP4/abapindx.htm
http://www.sapgenie.com/abap/index.htm
http://www.sap-img.com/abap.htm
http://www.sapdevelopment.co.uk/tips/tipshome.htm
http://help.sap.com/printdocu/core/Print46c/en/Data/Index_en.htm
http://sap.ittoolbox.com/nav/t.asp?t=322&p=322&h1=322
http://sap.ittoolbox.com/nav/t.asp?t=448&p=448&h1=448
http://www.thespot4sap.com/
http://www.kabai.com/abaps/q.htm
http://www.geocities.com/mpioud/Abap_programs.html
http://www.sapgenie.com/abap/tips_and_tricks.htm
http://www.sapassist.com/code/d.asp?whichpage=1&pagesize=10&i=10&a=c&o=&t=&q=&qt=
https://www.sdn.sap.com/irj/sdn/collaboration
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/HRINF/HRINF.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CAARCHR/CAARCHR.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PAXX/PAXX.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/PYINT/PYINT_DATAEX.pdf -
Hi,
While Hiring an Employee,the Basic salary was entered as 10,000/- instead of 11,000/-.It was noticed after two Months,Now what is the procedure to give that Employee the remaining 1,000/- salary for Jan,Feb&11,000/- from March?
Regards,
Chikky.Hi;
In order to do that you have to run retroactive calculation.
To be able to do that you have to set the Earliest retro acctg period to 2 months before from the menu reached with transaction pa03
It will be like: payroll period 04.2011 earliest retroactive acctg period 02.2011
After that instead of 10.000 enter 11.000 as basic pay in it0008.
when you run payroll for that employee his payroll will be calculated since 02.2011 and the difference will be added to the last payroll. After that you can adjust the payroll control record back to 04.2011 and run payrollfor other employees.
If this will be done just for one employee you can change the earliest retroactive calculating date from pa30 - choose employee- utilities - change payroll status enter date to earliest pers. RA date to the related area like 01.02.2011. After that instead of 10.000 enter 11.000 as basic pay in it0008.
when you run payroll for that employee his payroll will be calculated since 02.2011 and the difference will be added to the last payroll.
also there can be work around way to solve this. for last two months amount which has not been paid is 2000 totally. you can enter an additional payment for that. If there is special calculation case for your country because of localization you may have to do some extra customizing but you can pay 2000 from addtional payments too. -
Unable to run FIMPostInstallScriptsForDataWarehouse for FIM Reporting
Hi Everyone,
I am configuring FIM Reporting in which initially I installed scsm 2012 r2 which was not supported and after the uninstallation I installed scsm 2012 sp1,after the installation of scsm management server 2012 sp1 and dataware house when I am running the "FIMPostInstallScriptsForDataWarehouse"
script it says the following error message in the first screen and when I am trying to install the snappins then it says me to delete this existing files in the second screen.
My question is how and where should go I go and delete that exisiting snappins so that the script can run. please find the below screen shots
+Hi,
Can you check payroll status of the mentioned employees in PA30. (IT0003)
See whether employee number has been locked for payroll or there are dates in the fields for retroactive calculation etc.
Regards;
Okan -
Unable to run payroll for two employees who rejoined the company.
Dear Community,
We are unable to run payroll for two employees who have rejoined the company.
Any guidance would be appreciated.
Thanks in advance.Hi,
Can you check payroll status of the mentioned employees in PA30. (IT0003)
See whether employee number has been locked for payroll or there are dates in the fields for retroactive calculation etc.
Regards;
Okan -
Error occurred when delimiting records
Hi Experts,
When I am delimiting IT0008 err is coming
"Error occurred when delimiting records"
How to solve.
Regards,
Tomesh
Edited by: Tomesh Sahu on Jun 16, 2008 5:10 PMHi,
You cannot delimit IT0008 due to fact that Time constraint=1. 1 record should always exist in the system even if person is terminated.
IT0008 shoudl not be delimited due to some retroactive calculations if any.
Similar infotype that cannot be delimited are 0000, 0001 and 0002, They shoud always exist in the system even if person is terminated.
Why you not think about action which will change status of employee to something that will not be processed via payroll and when Person is back just Rehire him/her or run another action which will update status to Active.
Regards,
Ani
Edited by: Ani Arsova on Jun 16, 2008 11:52 PM -
Photosmart B8550 driver for Maverick NOT AVAILABLE
Photosmart B8550 driver for Maverick NOT AVAILABLE.
The website should say that it has it, or it doesn't! So ambiguious...
Call tech support and for a kindly $25 box we'll show a work around. I interpret that to be obsolesence. You are up to date or you are not. The refund of the money is more complicated to monitor than when the softweare patch would be available, at least 5 times more complicated. Wait for the bank statement to see if ther money was refunded, and than follow up for the refund, come ON!Tomesh,
Problem is not so clear but I can say you can try these things.
1. Are you trying to do retroactive calculation for particular employee . If yes, then check the driver perk wage type validity period.
2. If you are using some constant table to calculate Driver's perk value then you must check that contact table and dates mentioned there.
Maybe you are looking for
-
How To add a second eSata drive once first drive capacity is reached
What upgrade options are available once an eSata drive recording capacity is reached? Once an eSata drive connected to CHS 435HDC DVR reaches recording capacity, is there a way for a second external eSata drives to be connected and used as external s
-
How to populate drop down list in infopath 2010 with form Active Directory resources.
I want to populate drop down list in infopath 2010 with Active directory resources. Kindly let me know how to do this.
-
Has anyone else had his/her phone alarm (on the clock app) go off by itself, without being set, and with a very weird sound? Happened to me at 11:34 pm last night (Oct 28, 2013). I'm using an iPhone 5 with iOS 6. Sound was named something like "Orar
-
Help my iMessage isn't working because my email is only showing as my thing to where people can contact me instead of my number. I'm new to the whole iphone team and I really need help. I tried the whole going into settings and selected my phone numb
-
Note 980690 having the status of "cannot be implemented" Wonder the blocking factor of this note 980690 is caused by the transport that we have created or not. This transport was created base on step 20 to 33 of note 980690, well before the snote imp