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

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

  • Payroll retroactivity log

    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

  • G/L accounts to retro

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

  • Urgent issue in HR-ABAP

    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 won’t 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
    Praveen

    sorry 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,
    suresh

    Hi 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???

  • ABAP HR MATERIAL REQUIRED

    HI FRIENDS,
    CAN ANYONE SEND ME THE ABAP-HR MATERIAL .
    THAXS AND REGARDS.
    HITESH

    Maybe this link can be helpfull
    http://www.sapdevelopment.co.uk/hr/hr_infotypes2.htm
    Have a look at http://www.sap-img.com/human/how-to-create-a-hr-infotype.htm, but have also a look at this thread
    https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/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 Infotype’s infotype characteristics screen and use as the reference to fill yours) 
    22) Save your entries. 
    23) Now the Infotype is created and ready to use. 
    24) If you want to change the layout of the Infotype as per your requirement… 
    25) In the PM01 initial screen…Select ‘Screen’ radio button and give 2000 as the screen name, then click on edit. 
    26) In the next screen.. Select ‘Layout Editor’ and click ‘Change’. 
    27) Screen default layout appears…here you can design/modify the screen..change the attributes of the fields..etc. 
    28) Save and activate. (Don’t forget to ‘Activate at every level) 
    InfoSets in the HR Application 
    You can use SAP Query in HR to report on HR data. Queries are maintained as described in Creating Queries. The special features of queries created for HR are described in Maintaining Queries in the Human Resources Application. The maintenance procedure for HR InfoSets differs from the described procedure inasmuch as HR data fields are grouped together in infotypes.
    InfoSet management in SAP Query is also used for InfoSet Query. For further information, see Functions for Managing InfoSets.
    If you want to create InfoSets for HR, you can use logical databases PNP, PAP, and PCH (see HR Logical Databases). The database you must use to create your InfoSet depends on the component in which the data you want to report on is stored.
    The reports you can execute using InfoSets based on logical databases PNP or PCH are similar, but differ in that they can select different objects. The following table describes the connection between the logical database, and the infotypes you can include in an InfoSet. It also provides you with one or two examples of reports that you can execute using the appropriate InfoSets.
    Logical database     PNP     PCH     PAP
    Selection of     Persons     Objects from Personnel Planning     Applicants
    Infotypes that can be included in the InfoSet     Infotypes for
    •     Personnel Administration (0000-0999)
    •     Time Management (2000-2999)
    •     Payroll infotypes
    •     Infotypes for Personnel Planning objects that can be related to persons     If the object type is specified:
    •     Infotypes for the object type
    •     Infotypes for objects that can be related to the specified object type
    If the object type is not specified:
    •     All infotypes     •     Infotypes for Recruitment (4000-4999)
    •     Some infotypes for Personnel Administration (such as 0001 and 0002)
         •     Customer infotypes
    Reporting examples     •     Selection of all persons who participated in a specific business event, output of prices for reserved business events
    •     Selection of all persons assigned to a specific personnel area, output of qualifications held by these persons     •     Selection of all business events held in London in March, output of all persons who participated in these business events
    •     Selection of all positions assigned to a specific organizational unit, output of all persons assigned to the positions     •     Selection of all applicants hired last year to work on special projects, output of addresses for the applicants selected
    Creating InfoSets
    The maintenance procedure for HR InfoSets differs from the procedure described so far in this section inasmuch as HR data fields are grouped together in infotypes. To set up an InfoSet for the HR application, proceed as follows:
    1.     On the initial screen for maintaining InfoSets, enter a name for the InfoSet and choose  Create.
    2.     On the next screen, enter a name for the InfoSet and select one of the HR logical databases in accordance with your reporting requirements.
    Customer infotypes can be created on all HR logical databases. In each individual case, therefore, you must decide which database to select so that you can report on customer infotypes.
    This screen enables you to enter an authorization group. All of the queries that are subsequently created using this InfoSet can only be executed by persons who have this authorization group.
    3.     Choose  .
    This takes you to the Infotype Selection for InfoSet .
    The logical HR database uses the table APPLICANT. You must declare it in the TABLES statement.
    At the GET APPLICANT event, the APPLICANT structure contains the data for an applicant number chosen on the basis of selection screen entries.
    The APPLICANT-APLNO field contains the applicant number which is selected for processing.
    Only the APPLICANT-APLNO field should be read from the work area of the APPLICANT table. The other fields are intended for internal use only.
    2.7     Authorization Checks in Reporting (PA-APP)
    Generally, authorization checks in reporting do not differ from those in the transactions. Since data access in reporting is always of the read type, the system checks for a read authorization; the authorization group must be R or *.
    In some situations, you may want to use a simplified authorization check when running reports. The object RPABAP is required for the check as well as the object RPORGIN; if these authorizations are available, a simpler and faster check is performed.
    If the report cannot read certain applicant data due to lack of authorization, data for these persons is not processed at the GET APPLICANT time point. A note appears at the end of the list stating the number of applicants who were skipped due to lack of authorization.
    2.8     Views
    Introduction
    When evaluating data, we distinguish between the logical and the physical view.
    The physical view corresponds to the form in which the infotype data is stored in the HR tables. This data is stored in infotype records with a validity period.
    In the logical view, the validity periods of individual fields are determined for several infotype records. For example, for an evaluation, the time period during which an employee worked at a particular job may be important, irrespective of whether a company code, personnel area or cost center change occurred during this time.
    Data from several infotypes can also be provided for a specific partial period. When calculating partial payroll periods, it is especially important that data on basic pay, work schedule and cost distribution are provided for the relevant partial period.
    These two types of logical views are implemented in the projection and join.
    &#61607;     Join
    &#61607;     Projection
    &#61607;     Join and Projection
    &#61607;     Time-Dependent Control Tables
    &#61607;     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.
    &#61607;     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.
    &#61607;     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?
    &#61607;     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
    &#61607;     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).
    &#61607;     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 employee’s 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
    &#61607;     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 &#61614; ABAP Workbench &#61614; 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.
    &#61607;     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.
    &#61607;     Customer-specific RMAC modules should begin with a special character.
    The macros defined in the control table TRMAC can be used by all reports.
    &#61607;     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

  • Help on ABAP HR

    Hi,
    i learned ABAP HR can any body help me materials regardign this
    any body having specifications regardsing ABAP HR it will be more helpfull to this id <b><REMOVED BY MODERATOR></b>
    Message was edited by:
            Alvaro Tejada Galindo

    Maybe this link can be helpfull
    http://www.sapdevelopment.co.uk/hr/hr_infotypes2.htm
    Have a look at http://www.sap-img.com/human/how-to-create-a-hr-infotype.htm, but have also a look at this thread
    https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/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 Infotype’s infotype characteristics screen and use as the reference to fill yours)
    22) Save your entries.
    23) Now the Infotype is created and ready to use.
    24) If you want to change the layout of the Infotype as per your requirement…
    25) In the PM01 initial screen…Select ‘Screen’ radio button and give 2000 as the screen name, then click on edit.
    26) In the next screen.. Select ‘Layout Editor’ and click ‘Change’.
    27) Screen default layout appears…here you can design/modify the screen..change the attributes of the fields..etc.
    28) Save and activate. (Don’t forget to ‘Activate at every level)
    InfoSets in the HR Application
    You can use SAP Query in HR to report on HR data. Queries are maintained as described in Creating Queries. The special features of queries created for HR are described in Maintaining Queries in the Human Resources Application. The maintenance procedure for HR InfoSets differs from the described procedure inasmuch as HR data fields are grouped together in infotypes.
    InfoSet management in SAP Query is also used for InfoSet Query. For further information, see Functions for Managing InfoSets.
    If you want to create InfoSets for HR, you can use logical databases PNP, PAP, and PCH (see HR Logical Databases). The database you must use to create your InfoSet depends on the component in which the data you want to report on is stored.
    The reports you can execute using InfoSets based on logical databases PNP or PCH are similar, but differ in that they can select different objects. The following table describes the connection between the logical database, and the infotypes you can include in an InfoSet. It also provides you with one or two examples of reports that you can execute using the appropriate InfoSets.
    Logical database PNP PCH PAP
    Selection of Persons Objects from Personnel Planning Applicants
    Infotypes that can be included in the InfoSet Infotypes for
    • Personnel Administration (0000-0999)
    • Time Management (2000-2999)
    • Payroll infotypes
    • Infotypes for Personnel Planning objects that can be related to persons If the object type is specified:
    • Infotypes for the object type
    • Infotypes for objects that can be related to the specified object type
    If the object type is not specified:
    • All infotypes • Infotypes for Recruitment (4000-4999)
    • Some infotypes for Personnel Administration (such as 0001 and 0002)
    • Customer infotypes
    Reporting examples • Selection of all persons who participated in a specific business event, output of prices for reserved business events
    • Selection of all persons assigned to a specific personnel area, output of qualifications held by these persons • Selection of all business events held in London in March, output of all persons who participated in these business events
    • Selection of all positions assigned to a specific organizational unit, output of all persons assigned to the positions • Selection of all applicants hired last year to work on special projects, output of addresses for the applicants selected
    Creating InfoSets
    The maintenance procedure for HR InfoSets differs from the procedure described so far in this section inasmuch as HR data fields are grouped together in infotypes. To set up an InfoSet for the HR application, proceed as follows:
    1. On the initial screen for maintaining InfoSets, enter a name for the InfoSet and choose Create.
    2. On the next screen, enter a name for the InfoSet and select one of the HR logical databases in accordance with your reporting requirements.
    Customer infotypes can be created on all HR logical databases. In each individual case, therefore, you must decide which database to select so that you can report on customer infotypes.
    This screen enables you to enter an authorization group. All of the queries that are subsequently created using this InfoSet can only be executed by persons who have this authorization group.
    3. Choose .
    This takes you to the Infotype Selection for InfoSet .
    The logical HR database uses the table APPLICANT. You must declare it in the TABLES statement.
    At the GET APPLICANT event, the APPLICANT structure contains the data for an applicant number chosen on the basis of selection screen entries.
    The APPLICANT-APLNO field contains the applicant number which is selected for processing.
    Only the APPLICANT-APLNO field should be read from the work area of the APPLICANT table. The other fields are intended for internal use only.
    2.7 Authorization Checks in Reporting (PA-APP)
    Generally, authorization checks in reporting do not differ from those in the transactions. Since data access in reporting is always of the read type, the system checks for a read authorization; the authorization group must be R or *.
    In some situations, you may want to use a simplified authorization check when running reports. The object RPABAP is required for the check as well as the object RPORGIN; if these authorizations are available, a simpler and faster check is performed.
    If the report cannot read certain applicant data due to lack of authorization, data for these persons is not processed at the GET APPLICANT time point. A note appears at the end of the list stating the number of applicants who were skipped due to lack of authorization.
    2.8 Views
    Introduction
    When evaluating data, we distinguish between the logical and the physical view.
    The physical view corresponds to the form in which the infotype data is stored in the HR tables. This data is stored in infotype records with a validity period.
    In the logical view, the validity periods of individual fields are determined for several infotype records. For example, for an evaluation, the time period during which an employee worked at a particular job may be important, irrespective of whether a company code, personnel area or cost center change occurred during this time.
    Data from several infotypes can also be provided for a specific partial period. When calculating partial payroll periods, it is especially important that data on basic pay, work schedule and cost distribution are provided for the relevant partial period.
    These two types of logical views are implemented in the projection and join.
    &#61607; Join
    &#61607; Projection
    &#61607; Join and Projection
    &#61607; Time-Dependent Control Tables
    &#61607; 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.
    &#61607; 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.
    &#61607; 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?
    &#61607; 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
    &#61607; 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).
    &#61607; 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 employee’s 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
    &#61607; 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 &#61614; ABAP Workbench &#61614; 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.
    &#61607; 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.
    &#61607; Customer-specific RMAC modules should begin with a special character.
    The macros defined in the control table TRMAC can be used by all reports.
    &#61607; 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

  • Infotype 0008

    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 PM

    Hi,
    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