Client Requirements

The client would like to report on employees who come late or leave early and also report on unauthorized absence. This is required for working days as well as for attendance on public holidays and OFF days.

There are only 2 shifts – day shift and night shift - in the plant and an employee can work during one of the shifts. All working days of each shift have the same planned start time and planned end time.

When an employee is working on a public holiday and the daily work schedule is not OFF, then the start time and end time of the daily work schedule will be used to determine if the employee has come late or left early. If an employee works on OFF day or on public holiday, it will be counted as overtime.

When the employee is working on a day with daily work schedule as OFF, the planned start time and planned end time can differ. Hence, on some OFF days, the planned start time and planned end time can be 08:15 and 17:45 respectively and on some days, they can be 09:00 and 13:30 respectively.

Below are the conditions for late coming, early going and unauthorized absence.

• 0 min < {Clock In Time – Planned Start Time} < 60 min    =>     Late Coming
• 60 min =< {Clock In Time – Planned Start Time}             =>     May be an unauthorized absence. The time administrator/ supervisor will determine whether there is a need for unauthorized absence or not.
• 0 min < {Planned End Time – Clock Out Time} < 60 min    =>     Early Going
• 60 min =< {Planned End Time – Clock Out Time}             =>     May be an unauthorized absence. The time administrator/ supervisor will determine whether there is a need for unauthorized absence or not.

If clock in and clock out times are both missing on a working day, then the time administrator/supervisor must get informed about the employee not being at work. The time administrator/ supervisor will determine the cause of absence and then accordingly apply for unauthorized absence if needed.

Solution Design

The solution on late coming, early going and unauthorized absence can be achieved based on custom time types and PCRs.

I will create five time types as below:

• ZVB7– This time type will get generated if the employee is late by more than 0 min but less than 60 min when compared to shift start time. The time type will contain the decimalized min.

• ZVB8– This time type will get generated if the employee leaves early by more than 0 min but less than 60 min when compared to shift end time. The time type will contain the decimalized min.

• ZVB9– This time type will get generated if the employee comes to office more than 60 min late than the shift start time. This may bring following possibilities:

• Employee is actually late by more than 60 min
• Employee is on leave during the first half of the shift (IT2001 record)
• Employee is in workshop at some other location during the first half (IT2002 record)

Hence, it is advisable that the system generates a time type with the decimalized time and a system message to the time administrator where he can take a judicious decision of handling this. If the employee is actually late by more than or equal to 60 min, then the time administrator will apply unauthorized leave for the duration in the system.

• ZVB0 – This time type will get generated if the employee leaves office early by more than 60 min than the shift end time. This may bring following possibilities:

• Employee actually left early by more than 60 min
• Employee is on leave during the second half of the shift (IT2001 record)
• Employee is in workshop at some other location during the second half (IT2002 record)

Hence, it is advisable that the system generates a time type with the decimalized time and a system message to the time administrator where he can take a judicious decision of handling this. If the employee actually left early by more than or equal to 60 min, then the time administrator will apply unauthorized leave for the duration in the system.

• ZVBA– This monthly time type will get generated from unauthorized absence type 0150 through a custom PCR.

The next step is to find a way to apply planned start time and planned end time for days with daily work schedule as OFF. But before we decide this, let us go through the WSRs for the two shifts that the client has.

WSR 3/US/10 D0001-01– This WSR uses PWS D001 and it is a 5D2X (5 working days 2 OFF days) PWS with DWS as D001 and OFF.

V_T508A

V_T551A

T550A

WSR 3/US/10 N0001-01– This WSR uses PWS N001 and it is a 5N2X (5 working days 2 OFF days) PWS with DWS as N001 and OFF.

V_T508A

V_T551A

T550A

Now, we are going to create constants in Table V_T511K to specify planned start time and planned end time for OFF days for each WSR.

V_T511K

Since these constants are date dependent, we can change the planned start time and planned end time on any particular OFF day by using delimitation functionality.

The first two constants will be considered for WSR D0001-01 when the employee works on OFF day. The next two constants will be considered for WSR N0001-01 when the employee works on OFF Day.

In this way, we need to define two constants for every WSR to be used in the plant to denote start time and end time of shift on OFF days.

Now we are going to define system messages which will get generated if the employee’s “clock in” is late by more than and equal to an hour compared to planned start time or if the employee’s “clock out” is early by more than and equal to an hour compared to planned end time. These messages can be accessed by time administrator through TCode PT_ERL00 or through PTMW.

V_T555E

The next step is to create a PCR which will generate time types and system messages. This is a very big PCR and hence, I will explain the logic in parts.

PCR ZVB1 Screenshot A

In PCR ZVB1 Screenshot A, we first determine whether the planned working hours is 0 or not using VARSTFREE. If it is not, it goes for processing at N and then if we check the day type of the day using VARSTDAYTY.

If the day type is *, the time pair is moved to output table using COLOP *. In the current scenario, only day types 0 and 1 are being used by client.

If the day type is 0, then we check if start and end times exist in the time pair or not using OUTTPEXTIM. If any of the start or end time is missing, the time pair gets processed through N and moves to output table using COLOP *. This time pair will later cause time evaluation to fail in PCR TE30 since either the clock in or clock out is missing.

If the start time and end time exist in the time pair, then it gets processed under Y and further processing happens under employee subgroup grouping specification A and B for PCR ZVB1 using PCY ZVB1A and PCY ZVB1B.

If the day type is 1, the processing is same as day type 0.

PCR ZVB1 Screenshot B

If the planned working hours is 0 (meaning DWS is OFF), the processing happens under Y (PCR ZVB1 Screenshot B). We check whether time pair has start and end times or not using OUTTPEXTIM.

If the start and end times don’t exist, then the time pair is processed under N and it is moved to output table using COLOP *.

If the start and end times do exist, the processing happens under Y and further processing happens under employee subgroup grouping specification C for PCR ZVB1 using PCY ZVB1C.

Under employee subgroup grouping A for PCR ZVB1, the “clock in” time of the time pair is read using HRS=PBEG. Then the planned start time of the shift is subtracted from “clock in” time using HRS-SWTB. The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB7 using ADDDBZVB7 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB9 using ADDDBZVB9, a message Z1 – “Employee came late > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

PCR ZVB1 Screenshot C

Under employee subgroup grouping B for PCR ZVB1, the planned end time of the shift is read using HRS=SWTE. Then the “clock out” time of the shift is subtracted from planned end time of the shift using HRS-PEND. The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB8 using ADDDBZVB8 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB0 using ADDDBZVB0, a message Z2 – “Employee left early > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

The time pair comes for processing under employee subgroup grouping C of PCR ZVB1 when the time pair has start and end times on an OFF day. The work schedule rule of the employee is read using OUTWPSHIFT.

If the WSR of the employee is D0001-01, the time pair gets processed under D0001-01. Further processing happens under employee subgroup grouping D & E using PCY ZVB1D and ZVB1E.

If the WSR of the employee is N0001-01, the time pair gets processed under N0001-01. Further processing happens under employee subgroup grouping F & G using PCY ZVB1F and ZVB1G.

If the WSR is other than D0001-01 and N0001-01, the processing happens under ******** and the time pair is moved to output table using COLOP *. This means that the late coming and early going time types won’t get generated in this case.

PCR ZVB1 Screenshot D

The time pair comes for processing under employee subgroup grouping D for WSR D0001-01 when start and end times exist in time pair for OFF day.

The “clock in” time of the time pair is read using HRS=PBEG. Then the planned start time of OFF day is subtracted from “clock in” time using HRS-CZD01B (The constant ZD01B is read from Table V_T511K). The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB7 using ADDDBZVB7 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB9 using ADDDBZVB9, a message Z1 – “Employee came late > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

PCR ZVB1 Screenshot E

The time pair comes for processing under employee subgroup grouping E for WSR D0001-01 when start and end times exist in time pair for OFF day.

The planned end time on OFF day is read using HRS=CZD01E (Constant ZD01E is read from Table V_T511K. Then the “clock out” time of the shift is subtracted from planned end time of the shift using HRS-PEND. The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB8 using ADDDBZVB8 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB0 using ADDDBZVB0, a message Z2 – “Employee left early > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

PCR ZVB1 Screenshot F

The time pair comes for processing under employee subgroup grouping F for WSR N0001-01 when start and end times exist in time pair for OFF day.

The “clock in” time of the time pair is read using HRS=PBEG. Then the planned start time of OFF day is subtracted from “clock in” time using HRS-CZN01B (The constant ZN01B is read from Table V_T511K). The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB7 using ADDDBZVB7 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB9 using ADDDBZVB9, a message Z1 – “Employee came late > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

PCR ZVB1 Screenshot G

The time pair comes for processing under employee subgroup grouping G for WSR N0001-01 when start and end times exist in time pair for OFF day.

The planned end time on OFF day is read using HRS=CZN01E (Constant ZN01E is read from Table V_T511K. Then the “clock out” time of the shift is subtracted from planned end time of the shift using HRS-PEND. The result is compared with 0 using HRS?0 and if it is less than and equal to 0, the time pair gets processed under * and is moved to output table using COLOP *.

If the result is greater than 0, then it is compared with 1 using HRS?1. If the result is less than 1, it gets processed under < and the result is added to time type ZVB8 using ADDDBZVB8 and the time type is moved to output table using COLOP *.

If the result is equal to or greater than 1, then the time pair gets processed under * and the result is added to time type ZVB0 using ADDDBZVB0, a message Z2 – “Employee left early > 1hr” gets generated in time evaluation and the time pair is moved to output table using COLOP *.

If a new WSR is being defined in the plant, then we must incorporate this WSR in the PCR ZVB1 at the point highlighted below. We should also define the constants for the WSR shift start and end times for OFF day. Also, the processing under D and E in PCR ZVB1 for existing WSR D0001-01 should be copied to the new ones and the constants of WSR D0001-01 are replaced by constants of new WSR.

PCR ZVB1 Screenshot H

An unauthorized absence 0150 is also created.

Table T554S

The time evaluation class of this absence type is maintained as 10. This has been done because all absences captured currently get a time type 0220 assigned to absence time pair through table V_T555Z using function TIMTP.

We would like to have a custom time type ZVBA – unauthorized absence assigned to absence type – unauthorized absence. This is done using PCR ZVB2.

V_554S_E

PCR ZVB2

This PCR helps to assign a unique time type ZVBA for unauthorized absence captured in IT2001. The PCR reads the pair type of the time pair using OUTTPPTYPE. If the pair type is anything other than 2, the time pair gets processed under * and it moves to output table using COLOP *.

If the pair type is 2, the time pair gets processed under 2 and the class for time evaluation for the absence captured on the particular day is read using VARABCAT. If the class is anything other than 10 (means absence captured is not unauthorized absence), the time pair moves to output table using COLOP *.

If the pair type is 10, the time pair gets processed under 10 and the no. of hours of unauthorized absence is added to time type ZVBA using ADDDBZVBA and the time pair is moved to output table using COLOP *.

The next step is to include both the PCRs in custom time schema ZTCN. The time schema ZTCN is a copy of time schema TM00 – Time Evaluation with Personnel Time Events.

Schema ZTCN

PCR ZVB1 is being processed by function RTIP because TIP table is being read in this PCR. Par 2 is GEN because it is called for all time types.

PCR ZVB2 is being processed by function RTIPA because TIP table is being read in this PCR only in case of absence on this day. Par 2 is GEN because it is called for all time types.

Let us now move towards testing this solution design.

I could think of 18 different scenarios and I tested them and all of them successfully passed.

IT0007

Work Schedule

Please note the below:

• 01-Jan-12 has DWS as OFF and is also a public holiday
• 02-Jan-12 has DWS as D001 and is also a public holiday
• 03-Jan-12 has DWS as D001 and is not a public holiday

Scenario 1: No time type generation if the employee neither comes late nor leaves early on a working day

Scenario 2: No time type generation if the employee neither comes late nor leaves early on a public holiday

Scenario 3: No time type generation if the employee neither comes late nor leaves early on a off day

IT2011

Time Evaluation Result– It is successful and doesn’t generate any time types.

01-Jan-12– Late coming, early going time types don’t get generated

02-Jan-12– Late coming, early going time types don’t get generated

03-Jan-12– Late coming, early going time types don’t get generated

Scenario 1:Pass

Scenario 2:Pass

Scenario 3:Pass

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 4: Employee came late by more than 0 min but less than 60 min on a working day

Scenario 5: Employee went early by more than 0 min but less than 60 min on a working day

Scenario 6: Employee came late by more than 0 min but less than 60 min on a public holiday

Scenario 7: Employee went early by more than 0 min but less than 60 min on a public holiday

Scenario 8: Employee came late by more than 0 min but less than 60 min on an off day

Scenario 9: Employee went early by more than 0 min but less than 60 min on an off day

IT2011

Time Evaluation Result– It is successful and generates early going and late coming time types.

01-Jan-12

02-Jan-12

03-Jan-13

RPTBAL00 Report – This report will display the late coming, early going and unauthorized absence for an employee.

RPTBAL00 Report Output

Scenario 4: Pass

Scenario 5: Pass

Scenario 6: Pass

Scenario 7: Pass

Scenario 8: Pass

Scenario 9: Pass

-------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 10: Employee came late by more than 60 min on a working day

Scenario 11: Employee went early by more than 60 min on a working day

Scenario 12: Employee came late by more than 60 min on a public holiday

Scenario 13: Employee went early by more than 60 min on a public holiday

Scenario 14: Employee came late by more than 60 min on an off day

Scenario 15: Employee went early by more than 60 min on an off day

IT2011

Time Evaluation– It is successful and generates late coming and early going time types and messages of being late or leaving early by more than an hour. These messages can also be read in PTMW or TCode PT_ERL00.

01-Jan-12

02-Jan-12

03-Jan-12

RPTBAL00 Report

RPTBAL00 Report Output

There are no existing absences or attendances for the first half or second half for the period 01-Jan-12 to 03-Jan-12. This means that the employee actually came late (> 1hr) and went early (>1 hr) on these days. We can’t capture any unauthorized absence on 01-Jan-12 and 02-Jan-12 as they are non-working days due to being OFF day and public holiday.

The unauthorized absence will be captured only for 03-Jan-12.

IT2001

Once the time evaluation rerun happens because of capture of unauthorized absence, the time type ZVBA gets generated.

Report RPTBAL00 Output

A variant of the report RPTBAL00 can be developed to display data related to the below time types only:

• ZVB7   -       Late Coming
• ZVB8   -       Early Going
• ZVBA  -        Unauthorized Absence

Scenario 10: Pass

Scenario 11: Pass

Scenario 12: Pass

Scenario 13: Pass

Scenario 14: Pass

Scenario 15: Pass

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 16: Employee didn’t turn up on a working day

Scenario 17: Employee didn’t turn up on a public holiday

Scenario 18: Employee didn’t turn up on an off day

IT2011

Time Evaluation– No message gets generated for 01-Jan-12 (OFF and public holiday) and 02-Jan-12 (public holiday) because they are non-working days and no attendance or time events have been captured for these days.

The time evaluation fails for 03-Jan-12 since there is no leave or attendance captured and time events are missing too. The message will go to time administrator in PTMW or can also be accessed using TCode PT_ERL00.

Unauthorized absence is captured in IT2001 since the employee was not at work and also didn’t have any pre-approved absence or attendance captured for 03-Jan-12.

IT2001

Time Evaluation– It runs successfully after absence is captured.

P2001

Table TES

RPTBAL00 Report

RPTBAL00 Report Output

Scenario 16: Pass

Scenario 17: Pass

Scenario 18: Pass

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Here I come to the end of this knowledge artifact. I hope you enjoyed reading through this document.

If you liked this document and found it to be beneficial, request you to please kindly rate it for the benefit of other users.

Warm regards,

Vivek Barnwal,

vianshu@gmail.com

1. Introduction – describing the process if SAP HCM in Russia Implementation.

I will describe in this case study the prerequsites and steps in order to implement SAP HCM functionality (OM, PA, TM, PY -modules)  on SAP HCM ECC 6.00 applicable for Russian client requirements.

If you are planning to implement or roll-out your HR Global Solution in  Russia, I recommend to read this article before  project estimation and implementation.
Russian SAP HCM  Solution is very  complex and requires a deep knowledge of Russian conditions and law peculiarities.  In order to understand immediately the depth of  solution complexity is enough to open  section for the Russian Payroll customizing  IMG-> Payroll-> Payroll: Russia:

Image1

I can mark that only one scheme of Russian Payroll driver - RUS0  is about 4810 lines of code. The typical Wage type catalog consists of round  1100 Wage types.
Before implementation  you also should  know that in Russia it is very strict regulation for document flow: orders , reporting to official authorities should be  in paper  and some of reporting should be uploaded in .xml format.

In Russian Solution you also should maintain a lot of Official Dictionaries, like OKPDTR, OKSO, Military Catalog,  KLADR  etc.

2. Prerequisites for RU- Implementation

There are the following mandatory requirements for the system that needs to be done, before the implementation in order to save your time and budget:

2.1. Installed Russian Language

Before the implementation it is obsolete to install   the Russian language in the system, because orders and reports should be generated only in Russian language and Information for it should be put on Russian.
Name of Object such as Positions, Job and Organizational units should be kept in Russian in IT 1000  Object and  IT 1002 Description and information also is input  for personal data in the IT 0002, 0016, 0022, 0290, 0294,0296, 0298

2.2. Check Licenses for  Adobe Document Services Credentials , which  are required  for Adobe interactive forms .

Most standard RU-forms and RU-orders for Russia were realized in .PDF format  on base of Adobe Interactive forms, which require licenses for the Adobe Document Services Credentials. If the license is absent, you will not be able to run the forms and orders. These links help you:

https://service.sap.com/sap/support/notes/944221
  https://www.sdn.sap.com/irj/sdn/weblogs ... xdepth%3D0

Installing AdobeDocument Services Credentials:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/39ce42e6-0401-0010-df96-e28d39742611
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/70aa75cc-6ac3-2910-c78c-ade192ec861e

2.3. Patch Levels

Before the implementation  you need also  to install  the latest Service Packs(SP), as in the past two years were greatly changes  the in Russian Law , e.g. Sick Leave payments  and Taxation. If you do not want to affect other countries by installing a new version of SP in your  global system, then install the latest SP  specially for Russia - Sub component SAP_HRCRU of SAP_HR - SAP_HRCRU. If you already have EHP4, I advise you to upgrade to EHP 5, thus you get a variety of reports on business trips, as well as improve the handling of Absence Quotas, and get improvements for Concurrent employment. In this case also you should check the activation of business function  HCM_LOC_CI_01, 02 and HCM_LOC_CI_19.

3. Organizational Management(OM)  Issues

3.1. Organizational Management Customizing

Generally the  Organizational management customizing  is typical as  for other countries. Features for Russian Solution are storing long names in the IT 1002 Description in order to output it in the orders and reports and maintaining Objects of working conditions. If you will implement EHP5 , so you can maintain a new Object OR Legal entity  for which is maintained IT 1655 legal  details which contained legal details for organization.

3.2. Organizational Management Customizing

If we speaking about Long names of positions and organizational units( the full name can be more than 150 Symbols), usually  the data for long names of objects is maintained for such Objects of  Organizational management like as the Position( S), Job ( C) and Organizational units (O) in the IT 1002 Description Subtype 0001 General Description  or make a copy of this subtype ( than put in table T7RURPTCST00 parameter  OBJLONGNAMES SUBTY XXXX , where XXXX is the number of  customer subtype )

The next requirement for Russia  is the maintenance of  OKPDTR Dictionary  (Russian National Classification of Occupations of Employees, Positions of Civil Servants and Wage Category), which consists of two sections - the profession of workers and office employees. This Dictionary  is loaded onto an Object  - Job (C).   in the IT 1000 Object  which  has 12-digit code and in IT 1002 Description -  full name of the profession. Loading is carried out via LSMW.

Special Russian objects - Objects working conditions are maintained In the Organizational Management :

• Regional condition - CR
• Hazardous condition - CH
• Special - long service condition - CL
• Special - calculated seniority condition –CT

These objects allow to  carry out  the calculation of seniority for these working conditions and than proceed it in the  Payroll and finally get  reporting for  the Pension fund of the Russian Federation. For these objects are maintained  IT 1000 Object on which the code of the working conditions is stored and long name is stored  in the IT 1002 Description. Further it will be created relationships in IT1001 Relationships with object Position or Job.

3.3. Reporting (OM):

3.3.1. Staff List (Form T-3)

Form T-3 is official unified form, which is necessary for the formation of  staffing list of the company.  Organizational units, Positions , Amount of salaries and allowances are introduced in this form.

At the enterprises are also developing  Staffing list , which is contained Names of employees, who  occupying staff positions or another position and which position are vacant  .

The customizing is made to the following path IMG-> Payroll-> Payroll: Russia-> Reporting-> Organizational Management-> Staff List (Form T-3).

3.4. Data Migration of Organizational Management(OM)

Data Migration for OM is provided by means of LSMW, it is  requires an additional upload  the Russian names of objects in IT 1000 and IT1002  .

3.4.1. Upload the OKPDTR Dictionary
Prepared dictionary  is loaded via LSMW object 777 through transaction PP02 for an object Job (C)

3.4.2. Loading working conditions.
The program HRUULSP1 is used to download the working conditions ( IMG-> Payroll-> Payroll: Russia-> Reporting-> Pension Insurance-> Pension Calculation for Special Working Conditions-> Upload Catalogs for Working -there is a help notes for this program).

4. Personnel Administration (PA) Issues

In the Russian part of Personnel Administration  is required to provide  a serious customizing  of info-types and action, as well as the   seniority calculation for employee and Personal  Orders and Forms.

In the end of Personnel Action , it is  creates a SAP HCM RU info type 0298 Personnel Orders (CIS), through which we get Personal orders for the employee (e.g. Order T-1 Hiring , Order T-8 , Termination order as well as employment contracts and supplementary agreements to them).

Info-types is adapted to correctly output the screen parts relating to the Russian data. Screen- 2033 is used for RU-infotypes.

The Russian employer   must keep records of employee seniority, the most common types of experience are  General seniority, Seniority for insurance, Job  seniority and Company  seniority (there are  also seniority for regional and hazardous working  conditions).
The common forms in RU-Personnel Administration  are Personal Orders ( t-1, T5, T-6, T8, T-11) and Forms T-2 - Employee Personal card  and T-7 – Vacation balance  are

4.1. Personnel Administration (PA) Issues Customizing

4.1.1. Customizing of Infotypes:

4.1.1.1. Names on Russian in IT0002 Personal Data

IT 0002 Personal data should be customized  to output fields  for the employee name in Russian. It  should be customized fields P0002-LNAMR, P0002-FNAMR, P0002-NAME2  and check its priority in table V_T522N fo outputting in the  reporting .
Also in this infotype is defined Citizenship of employee, which then affects on Payroll calculation.

Image 2 . IT0002 Personal Data

4.1.1.2. IT0006 Address 

For this info type 0006  is required to download  the  K LADR - Russian Classification of Addressees Data.  Classification is the official address of the Russian Federation. This dictionary is used to input information to the addresses , which  is will be required for the preparation of personalized reports and 2NDFL form .  If you enter the address data, it  is searched for matches  in this dictionary.  To upload in the system  the  KLADR it is   used  the program HRUUKLADRLOAD.  To download the latest version, please visit site of GNIVTS FTS  RU (http://www.gnivc.ru/inf_provision/classifiers_reference/kladr/)

The most common addresses are -    Home Address, Secondary Address , Birthday place ( required for reporting)

Image 3 . IT0006 Personal Data

4.1.1.3. IT 0016 Contract Elements

This international Info-type  has been enhanced , and now, when you create a contract, it  is automatically generated number of the contract employee. To customize automatic numbering  of   Contracts and Supplementation Agreements follow to this patch  IMG_>Personnel Management-> Personnel Administration-> Personal Data-> Russian-Specific Settings->  Employment Details-> Automatic Numbering for Contracts.

Also if you put in this infotype in Time limits Probation period it will be automatically created IT0019 Monitoring of Tasks with Term of Probation period

Image 4 . IT0016 Contract Elements

4.1.1.4. Customizing IT0022 Education

In this infotype you should to upload Dictionary  OKSO - National Classification of specialties according to education , as well as educational institutions, which are maintained in TableT7RUSCHOOL or you can input it directly in infotypes , If  it is activated parameter and value INSERT_SCHOOL - for report MP002200 in table T7RURPTCST00.

Image 5 . IT0022 Education

4.1.1.5. Customizing of IT 0024 Qualifications

In the info-type 0024 Qualifications are stored the data for language proficiency. Group of foreign language qualifications QK define in the  transaction OOQA  and than create  qualification Q for foreign languages. To enabling integration to display Qualification in   IT0024 put in table T77S0 -PLOGI QUALI A032 Q Integration switch for qualifications

Image 6. IT 0024 Qualification

4.1.1.6. Customizing subtypes of IT 0290 Documents and Certificates (CIS)

In the info-type 0290 Documents and Certificates (CIS) is stored information about on identification documents, documents for Tax priviledges, etc.

The commonly used subtypes of IT0290 Documents and Certificates (CIS)

03             Birth Certificate

04             Military Officer's ID Card

06             Minmorflot Passport

07             Military Card

09             Diplomatic Passport of RF Citizen

10              Foreign passport

11               Immigrant Certificate

14              Temporary ID Card of RF Citizen

21               Passport of RF Citizen

22              Travel Passport of RF Citizen

26              Sailor's Passport

27              Discharged Mil. Officer's Certificate

28              Driver's License

801           Tax Payer ID Card

802           Pension Insurance Certificate

803           Notice of Right to Tax Remission (RE)

To customize IT0290 0290 Documents and Certificates (CIS) follow to this patch  IMG->Personnel Management->Personnel Administration->Personal Data->Russian-Specific Settings->Documents and Certificates . 

In most cases, the subtype  07 Military Card is customized , information for this the military dictionary  in this subtype should be input  in  table V_T7RUM0.

For several subtypes  you need to prioritize the their date output for reporting in  table V_T7RU0290PRIOR for groups of documents:

• HA-Notice of Right to Tax Remission (Real Estate),
• IC-Identity card for tax accounts,
• IN-INN,
• LC-Passport/ID Card Data for Employment Contract,
• ML - Military card,
• ND-Document confirming non-resident status,
• PC-PFR card,
• PS PFR card (special codes),
• RD-Document confirming resident status,
• TA-Tax accounts

Image 7. IT 00290 Documents and Certificates (CIS) Subtype 07 Military Card

4.1.1.7. Customizing of IT0294 Employment Book (RU)

Under the seniority  it is assumed   the total duration of employment (work, education ) and other socially useful activities, such as paid and not paid activity . Seniority, as a special measure of the value of work, has a quantitative and qualitative characteristics. Quantitative characteristic of seniority is  the duration, the qualitative characteristics reflects the nature and conditions under which the work activity takes place (harmful working conditions, North area , etc.). Influence both on the Sick leave calculation , and on allowances  for work in different working conditions.

Basic settings:

For It 0294 Output customizing:

Personnel Management-> Personnel Administration-> Personal Data->Russian-Specific Settings->Employment Details-> Employment Book and Working Conditions->Determine Types of Labor and Other Activities

For Seniority calculation customizing:

IMG->Personnel Management->Personnel Administration->Evaluation Basis->Calculation of Employment Period

1.On the first step  is to configure Selection Rule.

1.1 Define Selection Criteria for Infotypes (It’s recommend to take data from the IT 0294)

(Table V_T525A_A  and V_T525Z)

1.2. Define Selection Exit:One way to select data in the Selection rule . Contains a functional module that selects data from infotypes  for IT 0294 Employment Book (CIS), in this case choose a program RUWB  (T525V)

2. Define  Selection Class . It is Combines one or more selection rules. (T525NT)

3. Define Valuation Model - Combines one or more Selection Classes

3.1 Sets for each Selection Classes  a weighting factor and sets  for the Selection Classes  limits (V_T525L)

3.2 Define rounding rules (V_T525E)

4.1Define Calculation Process -  Object that returns the value of seniority  for use in reports, function modules, payroll, etc. (V_T525P)

4.2 Symptom SENOR - assigning the return code for the split in the V_T525S

5.  Set records in the workbook in IT0294 Employment Book (CIS) - T7RUSEN

Image 8. IT 0294 Employment Book (CIS)

4.1.1.8. Customizing of IT0298 Personnel Orders (CIS)

Once the user completes the Action, the last step is to output info-type  0298 Personnel Orders (CIS). In this info-type it is automatically assigned  a number of orders and contracts,  signer person, and it is possible to see the Personal order.

Customizing patch : IMG_>Personnel Management-> Personnel Administration-> Personal Data-> Russian-Specific Settings->  Personnel Orders

To configure the Orders you should first configure the connection between Action and the reasons for action in table T7RURs (in the this table it  can be specified Details About Reasons for Personnel Actions, which allows to output  a long cause of the action). Table T7rur0 determines the relationship between Action and its reason  and the Report’s program output . Currently the most printed form of orders are derived through the Adobe Formular and updates are already being applied only to them.

Table 1. T7RUR0 Typical customizing for T-1 Hiring order .

In the feature  33298 is customized input mask for Action orders. Throughout the transaction  SNRO It is defined number ranges of orders for Object   HRYP298 for Company codes.

Image 9. IT 0298 Personnel orders

4.1.2. Customizing  of RU- Action

The main feature is that the information group has  at the end of the Action  a line in order to create and display the Info-type 0298 for example, where the operation DIS   allows you to immediately view during the Action process see the its personnel Order

Image 9. Creation and display IT 0298 Personnel Orders (CIS) in table T588D

Often there is a problem when it is customized Rehiring action on the same day after the employee was dismissal - the main problem is that it is checked  indicators in the table T529A  more details in the Note 923678 - HR-RU Rehiring or Reentry into company (on the next day too)

The most common of Dynamic action (Table T588Z) are created  typically when hiring and firing employees:
When you firing:

• Creation Print orders and Contracts
• Creation IT 0416 Time Quota Compensation , when during the Termination action ,it is limited  IT 2006 Absence Quotas.

4.1.3. Customizing of Reports (PA):

When it is customized Orders and Forms, it is  necessary to input all Data for Legal entities  in the table T7RU9a.

4.1.4. Customizing  of Orders (T-1, T-5, T-6, T-8, T-11)

Russian Personal orders   are both Individual (eg, the T-1 Hiring order – program HRUA_ORDER_T1) and Group  Orders (e.g. T-1A -Group order for hiring  -the program HRUA_ORDER_T1A).

If you implemented EHP5, then you can get Forms For Business trips ( T-9, T-10)  from the system.

4.1.5. T-2 (Personal Card)

The Form T-2 is  a statistical form ,that contains detailed information about each employee in a company.  According to Russian legislation, companies must prepare form T-2 for each employee, and keep the form up-to-date. For example, when an employee has personal or organizational data changes, it should be prepared  a new version of the form.

4.1.6. T-7 (Vacation Schedule)

Form T-7 is required by  State Committee for Statistics (Goskomstat) to prepare for every company in Russia. The form contains details about periods of planed vacation that your employees take each year. Goskomstat requires Legal entity  to prepare this form at the start of each year, and again whenever your employees change their vacation plans.

4.2 Data Migration (PA)

The data is loaded by the tool LSMW through the transaction PA40 and PA30. Provided and downloaded to the data for all active employees. The files for Personnel Administration Migration is the following

• Hiring employees
• Hiring Contractors. Employees who are in the company did not have a specific staff position is recorded on the Position with code 99999999
• Employees Termination
  • Home Address,
  • Birthday place
• IT 0009 Bank Details Migration
• IT 0021-Family Member/Dependents Migration;
• IT 0022 Education Migration
• IT 0024 Qualifications
• IT 0290 Documents and Certificates (CIS):
  • Passport of RF Citizen
  • Foreign passport
  • Travel Passport of RF Citizen
  • Pension Insurance Certificate
  • Tax Payer ID Card
  • Military Card

5. Time management  ( TM) Issues Customizing.

The Time management Customizing for Russia is in most cases the same as for  other Countries. The first step during Time management  customizing in Russia  should be Factory calendar’s configuration. Each year, the Russian government passes a new Factory calendar for next year, which governs transfers of holidays. Factory Calendar - a calendar  which  taking into account holidays and weekends, based on which are created the working schedules,   determined number of working hours per month and proceeded Payroll. It shows the true and accurate information about which days re weekends, holidays or reduced working days in accordance of the Government of the Russian Federation resolution.

In one case, if it was implemented Note 1020749 ,it should be customized  Special rules for transfer of public holidays in Factory Calendar – RU through the transaction SCAL.

Image 10. Special rules for RU-Factory Calendar.

In  another case,  it can be generated work schedules for the next year and then to do manually the work day transfer for each work schedule  through the transaction PT02 

5.1.1. Peculiarities of  Absences and Attendances Customizing

In Russian SAP HCM Solution there are a lot  of Absences types.  Absences can be divided into those that can use Absence Quota  and another one that doesn’t use Absence Quota.

Traditionally, creating the Absence Quota  for  Annual leave, it can be created for Additional types of absences that consume Absence Quota  for the Unregulated work or Seniority or for Work in  regions of the Far North.
Also, extensive list of absentees for the Sick Leave  and Maternity Leaves purposes:

• Sick leave
• Sick leave for taking care of a child under the age of 7
• Sick leave for taking care of a child aged from 7 to 15
• Home accident
• Sick leave for taking care of a family member
• Industrial injury
• Sick leave for taking care of a disabled child under the age of 3
• Sick leave for taking care of a child under the age of 7 in a hospital
• Maternity Leave
• Child Care leave 1,5 years
• Child Care Leave 3  years

Also for the Form  T-7 Vacation Balance it should be created  a Planned absence through  which to create on next year planned Vacation  (This Absence is not proceed in Time Evaluation, because it created with blocked status and displays only in Form T-7)

In Attendances  also is maintained  Work on weekends and holidays, business trips, overtimes etc.

5.1.2. Peculiarities of Absence and Attendance quota customizing

A very important point in Russia's SAP HCM Solution is Absence Quota generation. Let’s to consider it on  the example of Annual leave. If a person  worked  15 days and above, he is entitled to 2.33 of Absence quota in work month and if he works all year, so in the  end of the year he already has 28 days.

In this situation the problem arises when people will be dismissed  or want to know the number of Absence Quota days on date. It  is calculated Absence quota , depending on the period of cummulation. Imagine that it is calculated on daily base, then the number of limits can be anything and still have totally different numbers after the decimal point (t.e.365/12 * Number of days). The result should be rounded. The another problem is that standard SAP Solution doesn’t proceed the Absence quota deduction in order of unpaid leaves Maternity leaves.  Because of that on projects it is developed User-exit, which deducts the Absent Quota in accordance with those Absences from  Z –table.

The developed program calculates the Absence quota number  on the day of Termination  (or on any given day) by the formula: (28/366 * (366 - number of days> 14) / 366 * number of days worked). Next step I  adjust the rounding rules (table T556D):

Image 11. Rounding Rules for Annual Vacation Absence qouta.

SAP   is provided solution in EHP5,  where it can be excluded certain absence types from an employee's absence quota by adding the duration of those absence types to the end of the quota validity period: http://help.sap.com/erp2005_ehp_05/helpdata/en/fd/6bccca90774ea59a7e6a782212ba34/frameset.htm

Next problem is the right  control of Overtime  work. By law an employee may work out only 120 hours of overtime per  year. Control  is performed either manually or  through Attendance Quota or Time valuation.

5.2. Time Management Reporting  Customizing:

Form T-13 - Timesheets  is used to account for the time actually spent and (or) unfinished each employee organization to monitor compliance with the regime ( established by the employees working hours), to obtain data on hours worked, the calculation of remuneration and to compile statistical reports on the work. This report is run  only after the Time evaluation time.

5.2.1. FormT-13 Customizing

To Customize   this form  follow by this patch:

IMG-> Payroll-> Payroll: Russia-> Reporting-> Time Management-> Working Time Schedule (Form T-13)

5.3. Time management  (TM) Data Migration

For Time Data Migration is used  LSMW-tool .

5.3.1. AbsencesMigration

• IT 2001 – Absences
• IT 2002  - Attendances

5.3.2. AbsencequotaMigration

• It is migrated remains days for certain periods for  IT 2006 Absence Quota 
• It is migrated data type for vacation from IT 0041 Date Specifications

6. Payroll(PY) Issues

Russian Payroll is  very complex and difficult in SAP ERP HCM, like in US Payroll ,  so before its implementation, I strongly advise to find a Russian consultants in order to evaluate realization and real terms of implementation. To understand the depth of the problem look at the scheme RUS0.

6.1. Payroll (PY) Customizing :

For payroll, you should use the standard Payroll driver HRUCALC0 and the modified schema  RUS0, if it is installed EHP5, it could be use HRUCALC0_CE and schema RU0C.

6.2. RU PY Infotypes Customizing

6.2.1. It0009 BankDetails

Bank details  are designated by employee on infotype 0009.  It is required only configuration for this is population of the BNKA table with bank details such as key, bank name, address, etc. 

6.2.2. IT0048  Residence Status

The data on the residence status in the country influences on  the calculation of income tax: those employees who are not tax residents are charged 30% income tax, whereas tax residents are charged 13% tax rate.

It is described  the response of the system to a value in  IT  0048 Residence Status  in the feature of 33TXS

Image 12. IT 0048 Residence Status

6.2.3. IT0291 Tax and Social Ins. Payments (CIS)

This infotype is used for maintaining information about taxes and net payments.

Image 13. IT 0291 Tax and Social Ins. Payments (CIS)

6.2.4. IT0292 Add. Social Insurance Data (CIS)

Infotype 0292 is used for maintaining information about employee social group. This information is needed for sick payments.

Image 14.IT 0292 Add. Social Insurance Data (RU)

6.2.5. IT0293 Other and Previous Employers (RU)

In this infotype stored information about previous employers payments for current tax year.

Image 15. IT Add. Social Insurance Data (CIS)

6.2.6. IT0296 Garnishment Documents (CIS)

It is using for recording details of the  staffs garnishment documents. The system automatically create IT  0295 Garnishment Orders (RU) after completing the infotype   0296 Garnishment Documents (RU)  . Used to register the amount of  the garnishment document.  Impassible to enter the record in the  infotype 295 if there is no corresponding record in the infotype 0296.

Image 16.IT0296 Garnishment Documents (CIS)

6.2.7. IT0299 Tax Privileges (CIS)

IT 0299 Tax Privileges (CIS) is used to maintain individual tax exemptions: income tax exemption for a child, tax deduction (Art.218 Cl. 2), tax deduction (Art.218 Cl. 1, 219), material tax deduction etc. It is connected with individual Benefit flag in table T7rut3

           Image 17. IT0299 Tax Privileges (CIS)

6.3. WT Catalog Peculiarities

Wage type catalog  is  a list of charges, deductions and taxes. Russian WT catalog includes round 580 Technical Wage types,  round 448 Dialogs Wage types ( wage types with R*** and N*** are used for Regional and North Conditions).

When you create your own WT in RU WT Catalog , take the following into account:

Table 2. WT creation for RU-Wage type catalog

6.4. Payments peculiarities

There are also Fixied Salary payments and Hourly wage in Russia. In Russia there are a lot of compensatory payments connected with working conditions. Regional premium is made for work in the regions of Extreme North and equivalent areas. Calculation is made by multiplying regional premium rate by a sum of charges in a calculation month subject to regional premium rate charging.

It is customized  in the feature 33BMC For every personnel area is assigned Bonus Model. Bonus Model is maintained in table T7RUB1.  It is assigned to Bonus Model wage types and scales in table  T7RUB3.  The names of bonus scales are maintained in table  T7RUB4. The percent of allowances is input in  table   T7RUB5.

Payments for Harmful conditions are made for hours worked to employees whose positions are connected with insalubrious and hazards working conditions.  Usually it is input Payment for harmful working condition in It 0015 or put time in  IT 2002 or 2010 and then It is calculated through time evaluation than it will be proceed in rule RU25.

Payments for non-worked hours ( e.g. Vacation, Donor days) with average earnings maintained. Salary calculation is made on the basis of average earnings. The calculation period is considered as 12 calendar months preceding the month of the beginning of the event. Daily earnings are calculated by dividing the sum of earnings for the salary calculation period by the worked days for this period. Average earnings sum is defined as the product of average daily wages by the days of absence.

All types of paid absence refer to the appropriate Absence valuation rule, which connection is  configured in view V_554S_G.

Te common evaluated  absences  are grouped by the  Absence evaluation rule . The rule defines evaluation as a paid absence, and then generates a WT for accruals  . Absence evaluation rule is maintained in view V_T554C.

The Cumulation rules  are configured in view  V_T51AV_B in accordance with cumulative types of payments - the basis of average values.

6.5. Tax peculiarities

Personal income tax  is collected from all staff  that are tax residents of the Russian Federation, as well as from the staff members that get income from the sources of the Russian Federation and are not tax residents of the Russian Federation.

   Depending on category of tax payer Income tax can be 13, 30 and 35% 

Tax schema controls the payments for income tax.  It is customized IMG -> Payroll-> Payroll: Russia-> Tax and Social Insurance Payments-> Maintain Taxes and Social Insurance Payments.

Each Personnel area has Tax schema in table  V_T7RUP0. Tax schemas are described in table T7RUP1. Personnel grouping for Tax schema  is described in feature 33ТАХ.

Depending on thee return value of feature fro m the table T7RUP3 , it will catch up with some tax class. Tax classes is maintained in table  T7RUT1. Here you specify the scale for the deduction of taxes and benefits that must be applied to this tax.

To calculate the tax base tax payers can get standard tax deduction. Standard tax deductions are provided to the tax payer on the basis of his written statement and the documents confirming the right of such tax deductions.

The size of tax deductions is configured  in the view V_T7RUT3.

6.6. Sick leave peculiarities

In Russia there is a lot of  Sick leaves. Sick leaves are paid partially by Employer and by Social Security found.   Generally , Sick leave Payment is calculated on the basis of average earnings. The average daily wage is calculated by dividing the sum of earnings for 2 years at 730.

The function RUSIO proceed the  Sick leave. The total amount of average earnings (based on the data received from other employers) for each calendar year does not exceed the limit value base for the calculation of insurance premiums to the FSS RF, established in 2012 (463,000 rubles) , it is defined in table T511P . Amount of daily allowance is calculated by multiplying the average daily wage rate on the insurance seniority.

In table T7RUT5 is stored the amount for  Social group (which is defined in table T7RUT6)

In table V_T7RUT5_PAID you can assign the amount of sick leave days and WT which paid by employer.

Amount of  payments for sick leaves  ,e.g. 1,5 year Child care leave ,   is configured  in table T510J . Wage types  SI10, SI11  in IT 0293 stores  bases for the calculation of insurance premiums in the FSS. The Wage type SIRT in IT0015 stores  averages  rate for Sick leaves pavement.

6.7. Deductions peculiarities

Fines and Alimonies are maintained in table T7RUG1. Types of Garnishment orders are maintained in table T7RUG0.  It  is processed by  the function RUAID.
In the case of processing multiple deductions priorities are processed by function RUPRI.
The rules for deductions are adjusted in the table T7RUD3. Priority of processing in case , if it is not possible to deduct the whole sum, is stored in view of V_51P6_B.

6.8. RU Payroll Schema – RUS0

Table 3. Russian payroll Schema RUS0

6.9. Posting Peculiarities

Most posting configuration can be found at IMG path:  Payroll à Payroll: Russia à Reporting for Posting Results to Accounting.

• Table T52EK is where symbolic accounts must be defined.
• Table T52EL maps wage types to symbolic accounts  including posting details such as account type and credit/debit designation.
• Table T52EM is where EE grouping codes are defined.
• Feature PPMOD is where employees are assigned to grouping codes based on organizational data.
• Date identifier  for posting - V_T549S_B

6.10. Reporting (PY)

PY reporting is the also the  difficult  theme in Russian Reporting.  It is required to customize the output form in .PDF format and download the report in .xml format.

6.10.1. Pay slip

Pay slip is customized as usually in tr. PE51 .  It analyses classes for WT , which you defined for  output wage type in Pay slip

6.10.2. Form 4 FSS- form is for paymentof contributionsto the fund ofsocial insurance

6.10.3. Form RSV-1-form is for the calculation of accrued and paid insurance premiums to the Pension Fund of the Russian Federation, the insurance premiums for compulsory health insurance in the Federal Fund for compulsory medical insurance and territorial funds of compulsory medical insurance payers of insurance premiums, making payments and other compensation to individuals.

6.10.4. Form SZV 6-1-2- Information on accrued and paid insurance contributions for compulsory pension insurance of the insured and the insurance period of the insured , 6-2- Registry data on assessed and paid insurance contributions for compulsory pension insurance and the insurance period of the insured

6.10.5. Form  2 NDFL- a form on which employers report for taxes assessed on personal income

6.10.6. Payroll Sheet (Form T-53)- is payroll unified form

6.11. Data Migration (PY)

6.11.1. Data Migration for previous Employer

Create files for IT  0293   for WT /DA0 ,  SI09, SI10 аnd loadedtax deductions through LSMW.

6.11.2. Data Migration for Payroll Cluster

You must download the data for the year prior periods in order to ensure the correct calculation of pay for the average values ​​within a year after the start of a productive system For this purpose, load data into tables T558B and T558D, or use outdated table to load the T558A, which contains fewer fields than the previous table. Loading of the tools used, or LSMW - BUS7023 and IDOC to load the data, but in this case triggered numerous checks and loading is interrupted when transferring 100,000 entries and more. The second option - developing its program for downloading data base can be taken from this. Before the Migration  the Personnel Administration data must already be uploaded the staff, and WT should be customized

The order of loading:

1.Check the format and completeness of the data being loaded
2. Erase entries in the tables T558
3 Load the records into a table with the help of a program or LSMW
4. . Clean the cluster of loud personnel numbers with the report - RPUDEL20 or  its modification
5 Use a standard report RPUTRBK0 and move the date in IT 0003 "The status of the calculation of" employee number of load
6. Create your chart data is loaded into the cluster with scheme RU30 or  RLK0

          7. load the required personnel number with created Migration Scheme in   Payroll driver  HRUCALC0

SAP also proposed a new solution for PY Migration in the note 1677296 - HR-RU: Report HRUURU30 - Uploading old payroll data to SAP

Hi,

it has been suggested that I should have posted this blog in the HCM space, as the topic link doesn't seem to make it easily visible for those browsing the space. Apologies for the confusion!

Here's the link to the blog article posted in the Organisational Change space. Could be interesting to all HRIS project managers, project sponsors and process owners:

http://scn.sap.com/community/organizational-change-management/blog/2013/07/24/3-hands-on-techniques-for-managing-operational-change-in-hris-projects

Human Resource Management

HR– Play very important role – Deals with people not in money.

HCM  - Human Capital Management – Deals with both people and money.

Human Resource deals with employee and company policy. Always deals with people and money.

Modules in HR/HCM

Personal Administration– Information about each employees in company.

Time Management– Submit time sheets to PMO at the end of each month.

Recruitment– Deals with the Hiring employees.

Payroll– Deals with the Salary of employees and integrate with Finance.

Organization Management– This is the main module in HR/HCM. Others are sub-modules. It is deals with the following,

How many departments are there.

How many employee’s are there.

In which department employees are working.

This is the basic for run the other module.

Infotypes– Group of related data, records and etc..,
It always numeric it should be four character.

In Technical– It consist of 1 structure, 2 tables, 7 programs, and 3 module pool program are running in the back ground.

We have 5000 infotypes and there are secondary infotypes(Deals with configuration).

Personal Administration Infotypes - 0000 to 0999(Some infotypes deals with payroll).

Organizational Management Infotypes - 1000 to 1999.

Time Management Infotypes– 2000 to 2999.

Recruitment Infotypes– 4000 – 4999.

Custom Infotypes– 9000 – 9999( Only we create for personal administration organization management and recruitment).

Totally HR have 4 cluster tables

I) PCL1. II) PCL2. III)PCL3. IV)PCL4.

Secondary Infotypes– 5000 to 5999.

We can not create infotypes for time management.

For SAP future enhancement 3000 – 3999.

Infotypes Screens

1000 – Dummy screens.

2000 – Single level screen or entry screen.

3000 – Overview screen.

T.codes

PA30 – Employees administration.

PA20 – Display employee administration.

PA40 – To take action on employees(Termination, Suspends and etc.., ).

PB20 – Display the recruitment of applicant.

PB30 – Applicant Administration(For example some company have the policy for recruitment if any one attend interview then they will not allow to attend interview next 6 months ).

PB40 – Actions on applicant.

Organization management.

PPOME – Modify.

PPOCE – Create.

PPOSE – Display.

PM01 – Create or Enhancement(PA and Recruitment).

PPC1 – Create organization management infotypes.

PPCM – Enhancement organization management infotype.

Time constraint in Infotypes

Infotypes have 3 types of time constraint.

1 – Records will be only one.

Always only one records until leave from company. Don’t have multiple records.

2 – Not allow overlapping and have multiple records.

Ex – Employee have the type Trainee, contract, Permanent and etc..,

3 – Allow overlapping and also multiple records.

Ex – Some employees are deployed into many projects.

HR data is time dependent data. Because based on date we have to know whether the employee is active.

HR is time and country specific.

Payroll is differ to every company.

We can re-assign the employee here like ABAP consultant move to BI consultant.

PM01 – To create a custom infotype.

It has three includes.

First Includes – Key Values.

Second Includes – Administration include common to any infotypes.

Third Includes – Depends on Infotypes structure.

In last we have include for every infotypes for enhance the infotype.

Subtype– Ex – Address – It has different type permanent, Emergency, Contact, Temporary and etc..,

Using LDB we will get the data in HR. There are as follows,

PNP AND PNPCE. When we use PNP, PNPCE we can define our selection screen using HR report category. Instead of select…endselect. we can use provide…endprovide.

Using macros also we will get the data. They are as follows,

RP_PROVIDE_FROM_FRST – Initial records.

RP_PROVIDE_FROM_LAST – Latest records.

Organization management– It is an hierarchical manner like altimetrik->under this->CEO->Different departments.

It has different object types,

O – Organization Unit(Department, Place,and etc..,). It is an hierarchical manner. It has two type as follows,

Top to Bottom->A.

Bottom to Top->B.

S– Position.

K– Cost Center.

P– Employee number.

C– Job.

Q– Qualification.

D– Course type.

E– Course.

H– External person.

R– Resource and etc..,.

Relationship– It has 3 alpha numeric.

Based on relation ship we can get data as well as hierarchy extract data.

Ex – s ————> p(008).

HRP1001-> Relationship between object.

HRP1000-> Description about the object.

we can get the different relationship data using relat in (’008 ’002′ ’003′.)

Evaluation path– The combination of relationship.

Delimit-ion - One of term in HR like below.

Ex – 01-08-2011 to 31-08-201 – Developer.

01-09-2011 to 31-12-999 – Consultant.

Quota Based on Working more than 8 Hours a Day in +/-Time Management

I. Purpose

The Purpose of this document id to generate the absence Quotas using PCR.Which is often same for US Clients. I have taken the Example. Requirements may vary client to client. This document can be used for the reference.

Note: before looking at the document, basic knowledge in Absence Quota must be investigated carefully

II Requirement:

Part time employees who work on Hourly basis will get 0.5 Day quota on completion of more than 8 hours of shift on a particular Day shift.

Solution:

We need to group the Part time employees under different grouping as per our requirement.

Table: V_503_E

To full fill the requirement I have written A PCR to   check the number of working hours entered in info type 2011 and 2002. We have two info types from where we enter the timings. For positive employees.

Time Types: 1712

1715:

PCR Z0006

Inserting the PCR in TM04 (Alias ZM04)

·         Here Firstly we Query on Employee Group: OUTWPPERSG this will check the employee group “V”

·         OUTTPORIGS: Here we check the origin status of the Time Types.

The origin Indicators:

     E-     Time Events from 2011

     P-     Time Events from 2002

·         HRS=PNUM; this will check the Number of working hours in TIP Table for 2011 and 2002.

·         We will add the number of working hours to the Day Balance 1715

·         Next the HRS Operation will check the hours for More than 8

·         If it is less than 8 HRS will add 0 to the time type 1712

·         If It is greater than >8 this will add the 0.5 number of hours to the time type 1712.

TESTING

2011:

TIP Entry:

ABWKONTI:

After running The Live time Evaluation:

2006:

Thanks and Regards,

Srikanth Reddy Munugala

2 reports probably considered useful by HR professionals in any country are hidden away in the menu for British payroll.

They aim at analysing absenteism and can be used globally - provided approval from data privacy officers and workforce reps are obtained, where this is required. Intended for the UK the reportss miss some texts, if the user is not logged on in English.  

1. Spotting Absence Patterns

The report RPLABSG0_PATTERN (transaction code PC00_M08_PATTERN) checks, whether absenses of selected types (e.g. sickness) are frequently used to extend off periods (e.g. Friday or Monday to extend weekends). It can also spot absences related to:

• the employee's or his / her family members' birthdays
• special days (e.g. after company Christmas party or the FA cup finale)
• regularities such as 'same day every month' can be chosen on the selection screen

You can choose the relevant absence types on the selection screen. The report produces the following list with the right hand column showing how often sickness (or the absence types you selected) have occurred extending a weekend:

2. Bradford Score (Absence Spells Analysis)

The Bradford Score is a widely used method to indicate possible abuse of sick notes. Number of sick days as well as spells are used to calculate the score with the number of spells going into the formula squared thus being emphasised more strongly.The formula is simple:

(Bradford score) = (no spells) * (no spells) * (no days)

This means: an employee absent for 5 single days has a score of 125, whilst one five days absence only leads to a score of 5. A high score indicates that abuse of sick notes might be an issue, but it will always require the thorough consideration of the particular circumstances before any action is taken.

The SAP Standard report for calculating the Bradford Score is RPLABSG0_SPELLS (Transaction Code PC00_M08_SPELLS). As in the first report the absence types to be considered are chosen on the selection screen. Apart from the Bradford Score value (last column in picture) various other absence statistics as you know them from other reports are included:

Good to know:

• 2 absence records immediately following each other without a single day in between are counted as one spell. However, the infotypoe 2001 fields to link absences to each other as used in some countries (e.g. Austria, Germany or Spain) are not considered.

• Only full years can be reported on for the Bradford score.

• The report counts calendar days rather than working days.

Should these constrains not work for you, you can still enhance the standard reports or copy and amend them. I've used implicit enhancements to achieve this.

useful program to check configuration settings

Frequent error-select at least one plan for processing whilst enrolling the benefit plan for employee.Not defaulting.

Benefits->Flexible Administration->Programs->Employee Eligibility->Define Eligibility Rules

Benefit Eligibility Rule

View:   V_T5UBV

These are the two controls V_T5UBV and ELIGR feature to default plans for enrollment.

The above tables and feature need to be maintained to fix the error select at least one plan for processing.

Error2->The plan might not default because of table V_t74HA-Benefit adjustment reason.The validy if infotype records need to have the correct one checked.

like start of infotype record and end of record.

Error 3->wagteype might not populated in wagteypes for benefit plan node.

The reasons could be the start date of t512z for 0167 wagteypes for ex 01011800 could be the plan start date and in t512z if its 01011900 then the wagetypes might not  populate:)

http://sap.ittoolbox.com/groups/technical-functional/sap-hr/wage-types-for-benefit-plans-2654315%20No%20entry%20for%20infotype%200167

Client Situation

Our client requirement was to implement SAP HR Positive Time Management solution to record and evaluate the actual times of their blue collar workers. The client was installing time recording terminals which were not SAP CC1 certified. Only Clock In (Time Event Type P10) and Clock Out (Time Event Type P20) were required to be recorded.

The factory/plant had four production shops. Each production shop had two time recording terminals mounted on the wall - one for clock in and another for clock out. These time recording terminals didn't have any unique way to specify whether a time punched at time recording terminal is "clock in" or "clock out". Hence, there was a board mounted with the sign "Clock In" above "Clock In Time Recording Terminal" and with the sign "Clock Out" above "Clock Out Time Recording Terminal". Some employees had access to all production shops and some had access to few of them only. An employee could work in multiple production shops in the same shift. Each time an employee entered into a production shop, it was expected that he clocked in at the "Clock In Time Recording Terminal" while entering into the production shop and clocked out at the "Clock Out Time Recording Terminal" while leaving the production shop.

There were no turnstiles at the entrance of production shops and hence, there was a high chance that employees may forget to clock in or clock out while entering or leaving the production shops. Hence, we could have scenarios where an employee has a clock in data once and clock out data multiple times for the same shift.

For evaluation purposes, client wanted us to consider the first clock in and the last clock out since it was difficult to enforce employees to clock in while entering and clock out while leaving the production shop in absence of a turnstile. If the first clock in was missing, then it should be reported as a missing clock in. Also, if the last clock out was missing, then it should be reported as a missing clock out.

The time recording system would send a .txt file with all the time events (P10 & P20) data recorded for a shift for all employees in that shift in a predefined format to SAP R/3. These time events would be uploaded in IT2011 (Table TEVEN).

Hence, if the time events were recorded as shown in the table below, the first clock in will be blank and the last clock out will be 18:00:00.

There was no requirement to record break times and employees could clock in/clock out multiples times for the same shift. The break time would be considered from the daily work schedule.

Failed Solution Approach

For quite some time, this requirement was giving me sleepless nights. There were various approaches which I was trying out but none of them gave the desired results.

One such approach tried by me was to use operation VARST to read the first time pair (VARSTFIRST) and then use operation HRS=PBEG to capture the no. of hours and enter it into a time type.

Then use operation VARST to read the last time pair (VARSTLAST) and use operation HRS=PEND to capture the no. of hours and enter it into another time type.

Using the time types, I would modify the start time and end time using operation FILLP for the first time pair and ignore the remaining time pairs.

On the face of it, this solution looked good. However, it had inherent shortcomings.

Please refer the below screenshot for time events in IT2011 to understand the shortcomings. The employee recorded a clock in at 08:00:00 and then clock outs at 10:30:00, 14:00:00 and 18:00:00 on 03-Jan-12.

When the time evaluation is run, the time pairs formed get sorted as shown in the screenshot below:

SAP has sorted all the time pairs first by “From” and then by “To” in Table TIP. Hence, the PBEG of first time pair comes out to be blank and the PEND of the last time pair comes out to be 10.5000. However, the real time scenario demands that the first clock in should be 08.0000 and the last clock out should be 18.0000. Hence, this solution approach failed.

Solution Logic

I realized that I was not having clarity of thought on the logic to develop this solution and hence, the various attempts resulted in failure. Finally, I thought to myself that if I have to give this requirement to an ABAPer, what would be the requirement I would give to develop a program to find the first clock in and last clock out. Also, if the first clock in or last clock out was missing, the system would report that.

After some thinking, I came up with the below logic for ABAPer for determining the first clock in and last clock out:

• Find all the recordedclock ins for a shift from the time pairs formed in Table TIP from function P2011. Please note the word “recorded” which I have used. It means that I am trying to find earliest or latest recorded times from the time events that have actually got recorded at the time recording terminals.
• Out of the recorded clock ins, find the earliest recorded clock in and latest recorded clock in.
• Find all the recorded clock outs for the shift from the time pairs formed in Table TIP from function P2011.
• Out of this recorded clock outs, find the earliest recorded clock out and latest recorded clock out.
• Then compare the earliest recorded clock in with earliest recorded clock out. If the earliest recorded clock in is less than the earliest recorded clock out, then the earliest recorded clock in is the first clock in of the shift and should be called P10. If the earliest recorded clock in is greater than the earliest recorded clock out, then there is a missing clock in. Hence, the first clock in of the shift should be blank.
• Then compare the latest recorded clock out with the latest recorded clock in. If the latest recorded clock out is greater than the latest recorded clock in, then the latest recorded clock out is the last clock out of the shift and should be called P20. If the latest recorded clock out is less than the latest recorded clock in, then there is a missing clock out. Hence, the last clock out of the shift should be blank.

Let us now test this logic to the time events in our failed solution approach. Below table shows the time pairs formed in Table TIP from function P2011.

Earliest Recorded Clock In    =       08.0000

Latest Recorded Clock In     =       08.0000

Earliest Recorded Clock Out  =       10.5000

Latest Recorded Clock Out   =       18.0000

We see that the “earliest recorded clock in” (08.0000) is less than the “earliest recorded clock out” (10.5000) and hence, the “earliest recorded clock in” is the first clock in of the shift. This is correct.

The “latest recorded clock out” (18.0000) is greater than the “latest recorded clock in” (08.0000) and hence, the “latest recorded clock out” is the last clock out of the shift. This is correct too.

Hence, the above solution logic proved correct and I built custom PCRs and time types to fulfill the requirement based on this logic.

Solution Design

There are two key tables which we would need to maintain to build this solution.

• TPT_PAIRSTAT2        -        Pair Formation: Status Table
• V_T705B                 -        PDC Processing Statuses

Table TPT_PAIRSTAT2 determines how time pairs are formed in Table TIP.

Below is a partial screenshot of the Pair Formation Status Table.

From State: At any time, an employee has a state. This is the state in which the employee is in before the time event happens.

Time Event Type: The field shows the time event recorded when the employee is in a given state. It will change the state of the employee from “From state” to “To State”.

Unique Time Event Type: Time Event Type P01 can be used to record both clock in/clock out. If the “From state” of employee is absent before clock in and the “Time Event Type” is P01, then it means that the employee has clocked in. In such a case, the value of “Unique time event type” will be P10. This interpretation is defined in this field. Where no unique interpretation is required, the value of time event type is same as unique time event type. As shown in the screenshot above, the value of both time event type and unique time event type are P10 for “From state” – Absent before Clock In because no unique interpretation is needed.

To State: This is the state at which employee reaches from “From State” once the time event type is recorded.

Continue: This field is used for interim postings. Let us say that there is an interim posting between clock out and clock in and we would like to have two complete pairs – one from clock out to interim posting and another from interim posting to clock in. The first two events form the first time pair and the third event ends the new time pair taking the end event of previous time pair as the start event of the new time pair.

Closed: Time pairs are formed by a starting time event and an ending time event. However, if a time event is missing, then the pair won’t get formed or if there are multiple time events, incorrect time pairs may be formed. To avoid any errors, this check box should be checked for scenarios where the time event type is the ending time event and there is a missing starting time event type. This implies that the time event should create a new closed time pair only with “To” time and the “From” time will be blank. An example of this scenario is where clock in is missing and clock out is recorded.

Close: This field is meant to close an open time pair if it exists. If the employee is at work and a time event is recorded and this field is checked, then the pair should be closed. Fields Close and Closed are mutually exclusive. Both of them can’t be maintained at the same time for the same states and time event type.

New: This field means that a new time pair should be started.

Customer Adjustment: This field is used to specify PDC Processing Status and its reaction maintained in Table V_T705B.

Error: If the pair formation is not error free, it gives an error message in time evaluation run corresponding to the error message number maintained here.

Pair Formation Status: This field gives the status of the time pair formed – whether it is error free or not or clock in is missing or clock out is missing etc.

Let us now understand the PDC Processing Statuses Table V_T705B.

This table specifies the actions to be taken in situations where time pairs can’t be formed because the time events data don’t make sense.

PSGrp: This is Grouping of Personnel Subareas for Time Recording for which the same time types, time transfer specifications, access control groups, and message types are defined.

PDC Processing Status: This field displays the PDC Processing Status which defines the behavior to be taken into account during time pair formation.

Processing Status Text: This field displays the description of the PDC Processing Status.

Start Date: This field displays the start date from which the PDC Processing Status is valid.

End Date: This field displays the end date till which the PDC Processing Status is valid.

Reaction: The return code in field reaction will specify the reactions to be taken for PDC Processing Status.

Let us now study the values relevant for our scenarios from Pair Formation Status Table and the relevant values (C02 & C11) from PDC Processing Statuses Table.

TPT_PAIRSTAT2 Screenshot A – This shows the values in the table relevant for our scenarios.

V_T705B Screenshot B – The highlighted rows in the table show the values relevant for our scenarios.

Let us refer to the 2^nd and 6^th rows in Table TPT_PAIRSTAT2 Screenshot A. In both cases, employee was not at work and there was a clock out recorded. The system has to create a time pair with the clock out time event because the field “Closed” is checked. The “Customer adjustment” field has PDC Processing Status as C02 and the error message 21 (Clock in Missing) will get generated. The reaction field in Table V_T705B Screenshot B for PDC Processing Status C02 should be left blank to allow open time pair creation with only clock out time in Table TIP from function P2011. The time pair will have “From” field blank and “To” field with clock out time.

The other possible reaction value for PDC Processing Status C02 is 1. If 1 is maintained, then it doesn’t allow even creation of open time pair with just clock out data.

Below are the examples of system behavior with reaction as blank and as 1 for PDC Processing Status C02.

PDC Processing Status Scenario 1: Reaction indicator is blank for PDC Processing Status C02.

V_T705B

IT2011

P2011 – Open Pair Type gets created with clock out data and clock in is missing.

Time Evaluation Result – The time evaluation fails with error that clock in is missing.

PDC Processing Status Scenario 2: Reaction indicator is 1 for PDC Processing Status C02.

V_T705B

IT2011

Time Evaluation Result – The time evaluation fails at PCR TD20 which points out that time pair is not error free and has clock in missing. It doesn’t allow the system to reach function P2011 which creates open time pair with clock out time. Hence, this option is ruled out.

Let us refer to the 3^rd row in Table TPT_PAIRSTAT2 Screenshot A. The employee was at work and a clock in was recorded. The field “Close” is checked and hence, it will close the open pair. Also, the field “New” is checked and hence, it will start the creation of a new time pair. The PDC Processing Status in field “Customer Adjustment” is C11. The reaction indicator for PDC Processing Status C11 is 1. If the reaction is 1, the system will end ongoing time pair with the current clock in time and also start a new time pair with the same clock in time. If the reaction for PDC Processing Status is blank, the system will give an error that clock in is missing.

PDC Processing Status Scenario 3: Reaction indicator is 1 for PDC Processing Status C11.

V_T705B

IT2011 – Employee is at work (Clock In 08:00:00) and clocks in again (14:00:00). It means that there is a missing clock out between two clock ins.

P2011 – There wasn’t any clock out at 14.0000. However, the system closes the existing open pair with the clock in time and starts a new time pair with the same clock in time. This is due to PDC Processing Status C11 and its return code as 1.

Time Evaluation Result – The time evaluation run is successful.

PDC Processing Status Scenario 4: Reaction indicator is blank for PDC Processing Status C11.

V_T705B

IT2011 – Employee is at work (Clock In 08:00:00) and clocks in again (14:00:00). It means that there is a missing clock out between two clock ins.

Time Evaluation Result – The time evaluation fails at PCR TD20 and generates error during pair formation. It doesn’t allow system to reach function P2011 for processing. Hence, this option is ruled out.

After maintaining Pair Formation Status Table - TPT_PAIRSTAT2 and PDC Processing Statuses Table - V_T705B, the next step is to create time types. Below are the daily time types which are needed.

• Earliest Recorded Clock In – ZVB1
• Latest Recorded Clock In – ZVB2
• Earliest Recorded Clock Out – ZVB3
• Latest Recorded Clock Out – ZVB4
• First Clock In – ZVB5
• Last Clock Out – ZVB6

Go to TCode SM30 > Table V_T555A.

ZVB1 – Earliest Recorded Clock In

ZVB2 – Latest Recorded Clock In

ZVB3 – Earliest Recorded Clock Out

ZVB4 – Latest Recorded Clock Out

ZVB5 – First Clock In

ZVB6 – Last Clock Out

After creating the six daily time types, I created five PCRs as mentioned below:

• ZVB4   -        Find Earliest Recorded Clock In and Latest Recorded Clock In
• ZVB5   -        Find Earliest Recorded Clock Out and Latest Recorded Clock Out
• ZVB6   -        Determine First Clock In
• ZVB7   -        Determine Last Clock Out
• ZVB9   -        Form Time Pair in TIP using First Clock In & Last Clock Out

Let us now go inside each PCR to understand its functionality.

PCR ZVB4– The objective of PCR ZVB4 is to find the “earliest recorded clock in” and “latest recorded clock in” in a shift and feed the values in daily time types ZVB1 (earliest recorded clock in) and ZVB2 (latest recorded clock in).

If no clock in has been recorded, then the daily time types ZVB1 and ZVB2 won’t get generated. If only one clock in has been recorded, then both ZVB1 and ZVB2 will have the same value.

Below is a screenshot of PCR ZVB4.

Let us see how time pairs in TIP table get processed through PCR ZVB4.

• The PCR checks if start time exists in time pair or not using OUTTPEXBTM. If start time doesn’t exist (N), the time pair is moved to output table using COLOP *. If all time pairs of the shift don’t have start time, then time types ZVB1 and ZVB2 aren’t created. Hence, the values of ZVB1 and ZVB2 are 0.

• If the start time exists (Y) in time pair, the value of time type ZVB1 (Earliest Recorded Clock In) is read using HRS=DZVB1. If it is the first time pair with start time and getting processed in the rule, the value of ZVB1 will be 0. If it is not the first time pair with start time, then there will be some value in time type ZVB1.

• After reading the value of time type ZVB1, it is compared with 0 using HRS?0. If the value of ZVB1 is not greater than 0, it is processed under * and the start time of the time pair is read using HRS=PBEG. The start time is added to time types ZVB1 (earliest recorded clock in) and ZVB2 (latest recorded clock in) and the time pair is moved to output table using COLOP *.

• Let us assume that the first time pair with start time had start time as 10:00:00. Hence, the value of ZVB1 and ZVB2 will be 10.0000. Now let us assume that the next time pair with start time has start time as 08:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (10.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 08.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (10.0000) using HRS?DZVB1. Since the value of HRS=PBEB (08.0000) is not greater than ZVB1 (10.0000), the start time of this time pair is the new “earliest recorded clock in” for this shift and gets processed under *. Hence, the start time (08.0000) of the current time pair  is fed into daily time type ZVB1 after removing its old value 10.0000 using ADDDBZVB1Z and the time pair is moved to output table using COLOP *.

• Currently, the value of ZVB1 and ZVB2 are 08.0000 and 10.0000 respectively. Let us assume now that the next time pair with start time has start time as 15:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 08.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (08.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 15.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using HRS?DZVB1. Since the value of HRS=PBEG (15.0000) is greater than “earliest recorded clock in” time type ZVB1 (08.0000), the time pair gets processed under >. Then the value of HRS=PBEG (15.0000) is compared with “latest recorded clock in” time type ZVB2 (10.0000). Since the value of HRS=PBEB (15.0000) is greater than ZVB2 (10.0000), the start time of this time pair is the new “latest recorded clock in” for this shift and it gets processed under >. Hence, the start time (15.0000) of the current time pair  is fed into daily time type ZVB2 after removing its old value 10.0000 using ADDDBZVB2Z and the time pair is moved to output table using COLOP *.

• Currently, the value of ZVB1 and ZVB2 are 08.0000 and 15.0000 respectively. Let us assume now that the next time pair with start time has start time as 13:00:00. This time pair will get processed through Y (OUTTPEXBTM). The value of time type ZVB1 is read using HRS=DZVB1 (ZVB1 = 08.0000). This value is compared with 0 using HRS?0 and since the value of ZVB1 (08.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PBEG (HRS = 13.0000) and it is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using HRS?DZVB1. Since the value of HRS=PBEG (13.0000) is greater than “earliest recorded clock in” time type ZVB1 (08.0000), the time pair gets processed under >. Then the value of HRS=PBEG (13.0000) is compared with “latest recorded clock in” time type ZVB2 (15.0000). Since the value of HRS=PBEB (13.0000) is not greater than ZVB2 (15.0000), the start time of this time pair is not the new “latest recorded clock in” for this shift and it gets processed under *. Hence, this time pair is moved into output table using COLOP *.

• Finally, the value of “earliest recorded clock in” time type ZVB1 and “latest recorded clock in” time type ZVB2 are 08.0000 and 15.0000 respectively.

PCR ZVB5– The objective of PCR ZVB5 is to find the “earliest recorded clock out” and “latest recorded clock out” in a shift and feed the values into daily time types ZVB3 (earliest recorded clock out) and ZVB4 (latest recorded clock out).

If no clock out has been recorded, then the daily time types ZVB3 and ZVB4 won’t get generated. If only one clock out has been recorded, then both ZVB3 and ZVB4 will have the same value.

Below is a screenshot of PCR ZVB5.

Let us see how time pairs in TIP table get processed through PCR ZVB5.

• The PCR checks if end time exists in time pair or not using OUTTPEXETM. If end time doesn’t exist (N), the time pair is moved to output table using COLOP *. If all time pairs of the shift don’t have end time, then time types ZVB3 and ZVB4 aren’t created. Hence, the values of ZVB3 and ZVB4 are 0.

• If the end time exists (Y) in time pair, the value of time type ZVB3 (Earliest Recorded Clock Out) is read using HRS=DZVB3. If it is the first time pair with end time and getting processed in the rule, the value of ZVB3 will be 0. If it is not the first time pair with end time, then there will be some value in time type ZVB3.

• After reading the value of time type ZVB3, it is compared with 0 using HRS?0. If the value of ZVB3 is not greater than 0, then the time pair gets processed under * and the end time of the time pair is read using HRS=PEND. The end time is added to time types ZVB3 (earliest recorded clock out) and ZVB4 (latest recorded clock out) and the time pair is moved to output table using COLOP *.

• Let us assume that the first time pair with end time had end time as 12:00:00. Hence, the value of ZVB3 and ZVB4 will be 12.0000. Now let us assume that the next time pair with end time has end time as 10:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB3 = 12.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (12.0000) is greater than 0, the time pair gets processed under >. Then the end time of the time pair is read using HRS=PEND (HRS = 10.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (12.0000) using HRS?DZVB3. Since the value of HRS=PEND (10.0000) is not greater than ZVB3 (12.0000), the end time of this time pair is the new “earliest recorded clock out” for this shift and it gets processed under *. Hence, the end time (10.0000) of the current time pair is fed into daily time type ZVB3 after removing its old value 12.0000 using ADDDBZVB3Z and the time pair is moved to output table using COLOP *.

• Currently, the value of ZVB3 and ZVB4 are 10.0000 and 12.0000 respectively. Let us assume now that the next time pair with end time has end time as 18:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB3 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (10.0000) is greater than 0, the time pair gets processed under >. Then the end time of the time pair is read using HRS=PEND (HRS = 18.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (10.0000) using HRS?DZVB3. Since the value of HRS=PEND (18.0000) is greater than “earliest recorded clock out” time type ZVB3 (10.0000), the time pair gets processed under >. Then the value of HRS=PEND (18.0000) is compared with “latest recorded clock out” time type ZVB4 (12.0000). Since the value of HRS=PEND (18.0000) is greater than ZVB4 (12.0000), the end time of this time pair is the new “latest recorded clock out” for this shift and the time pair is processed under *. Hence, the end time (18.0000) of the current time pair  is fed into daily time type ZVB4 after removing its old value 12.0000 using ADDDBZVB4Z and the time pair is moved to output table using COLOP *.

• Currently, the value of ZVB3 and ZVB4 are 10.0000 and 18.0000 respectively. Let us assume now that the next time pair with end time has end time as 16:00:00. This time pair will get processed through Y (OUTTPEXETM). The value of time type ZVB3 is read using HRS=DZVB3 (ZVB1 = 10.0000). This value is compared with 0 using HRS?0 and since the value of ZVB3 (10.0000) is greater than 0, the time pair gets processed under >. Then the start time of the time pair is read using HRS=PEND (HRS = 16.0000) and it is compared with “earliest recorded clock out” time type ZVB3 (10.0000) using HRS?DZVB3. Since the value of HRS=PEND (16.0000) is greater than “earliest recorded clock out” time type ZVB3 (10.0000), the time pair gets processed under >. Then the value of HRS=PEND (16.0000) is compared with “latest recorded clock out” time type ZVB4 (18.0000). Since the value of HRS=PEND (16.0000) is less than ZVB4 (18.0000), the end time of this time pair is not the new “latest recorded clock out” for this shift and the time pair gets processed under <. Hence, this time pair is moved into output table using COLOP *.

• Finally, the value of “earliest recorded clock out” time type ZVB3 and “latest recorded clock out” time type ZVB4 are 10.0000 and 18.0000 respectively.

PCR ZVB6– The objective of PCR ZVB6 is to find the “first clock in” by comparing “earliest clock in” time type ZVB1 with “earliest clock out” time type ZVB3. If the value of ZVB1 is less than ZVB3, then ZVB1 is the “first clock in” and its value should be fed in time type ZVB5 – First Clock In.

If the value of ZVB1 is more than ZVB3, then there is a “missing clock in”. The “missing clock in” is the “first clock in” and hence, the value of ZVB5 will be 0.0000.

If ZVB1 was not created due to “missing clock in”, then the value of ZVB5 will be 0.0000 implying that there is a “missing clock in”.

Below is a screenshot of PCR ZVB6.

• Scenario 1: “Earliest Recorded Clock In” Time Type ZVB1 not created and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 - The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (blank) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. The value of “earliest recorded clock in” time type ZVB1 is read using HRS=DZVB1 and is fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. The value of ZVB5 is 0.0000 implying that the “first clock in” is missing.

• Scenario 2: “Earliest Recorded Clock In” Time Type ZVB1 has value 08.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 - The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (08.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. The value of “earliest recorded clock in” time type ZVB1 (08.0000) is read using HRS=DZVB1 and is fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 08.0000.

• Scenario 3: “Earliest Recorded Clock In” Time Type ZVB1 has value 12.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 10.0000 - The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (12.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (10.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The result is compared with “earliest recorded clock in” time type ZVB1 (12.0000) using operation HRS?DZVB1 and since the result is less than the value of ZVB1, it gets processed under <. Using HRS=0.00, the value is set to 0 and then fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 0.0000 implying that the “first clock in” is missing.

• Scenario 4: “Earliest Recorded Clock In” Time Type ZVB1 has value 08.0000 and “Earliest Recorded Clock Out” Time Type ZVB3 has value 0.0000 - The PCR ZVB6 reads the value of “earliest recorded clock in” time type ZVB1 (08.0000) using HRS=DZVB1 and then subtracts the value of “earliest recorded clock out” time type ZVB3 (0.0000) using HRS-DZVB3. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The result is compared with “earliest recorded clock in” time type ZVB1 (08.0000) using operation HRS?DZVB1 and since the result is equal to the value of ZVB1, it gets processed under =. The value of “earliest recorded clock in” time type ZVB1 (08.0000) is read using HRS=DZVB1 and then fed into “first clock in” time type ZVB5 using ADDDBZVB5Z. Hence, the value of ZVB5 is 08.0000.

PCR ZVB7– The objective of PCR ZVB7 is to find the “last clock out” by comparing “latest clock out” time type ZVB4 with “latest clock in” time type ZVB2. If the value of ZVB4 is greater than ZVB2, then ZVB4 is the “last clock out” and its value should be fed in time type ZVB6 – Last Clock Out.

If the value of ZVB4 is less than ZVB2, then there is a “missing clock out”. The “missing clock out” is the “last clock out” and hence, the value of ZVB6 will be 0.0000.

If ZVB4 was not created due to “missing clock out”, then the value of ZVB6 will be 0.0000 implying that there is a “missing clock out”.

Below is a screenshot of PCR ZVB7.

• Scenario 1: “Latest Recorded Clock Out” Time Type ZVB4 not created and “Latest Recorded Clock In” Time Type ZVB2 has value 12.0000 - The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (blank) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (12.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. Using HRS=0.00, the value is set to 0 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 0.0000 implying that the “last clock out” is missing.

• Scenario 2: “Latest Recorded Clock Out” Time Type ZVB4 has value 18.0000 and “Latest Recorded Clock In” Time Type ZVB2 has value 12.0000 - The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (18.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (12.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The value of “latest recorded clock out” time type ZVB4 (18.0000) is read using HRS=DZVB4 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 18.0000.

• Scenario 3: “Latest Recorded Clock Out” Time Type ZVB4 has value 14.0000 and “Latest Recorded Clock In” Time Type ZVB2 has value 16.0000 - The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (14.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (16.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is not greater than 0, it gets processed under *. Using HRS=0.00, the value is set to 0 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 0.0000 implying that the “last clock out” is missing.

• Scenario 4: “Latest Recorded Clock Out” Time Type ZVB4 has value 18.0000 and “Latest Recorded Clock In” Time Type ZVB2 not created - The PCR ZVB7 reads the value of “latest recorded clock out” time type ZVB4 (18.0000) using HRS=DZVB4 and then subtracts the value of “latest recorded clock in” time type ZVB2 (0.0000) using HRS-DZVB2. The result is compared with 0 using HRS?0 and since this is greater than 0, it gets processed under >. The value of “latest recorded clock out” time type ZVB4 (18.0000) is read using HRS=DZVB4 and then fed into “last clock out” time type ZVB6 using ADDDBZVB6Z. Hence, the value of ZVB6 is 18.0000.

By now, we have identified the “first clock in” and “last clock out” of a shift. We also have the solution logic in place to identify if the “first clock in” or “last clock out” of any shift is missing or not.

PCR ZVB9 - The next step is to create a time pair using the “first clock in” and “last clock out” that we have determined and process only this time pair for further evaluation. Any other time pair if present gets eliminated from further processing.

Below is the screenshot of PCR ZVB9.

The PCR ZVB9 uses VARSTFIRST to read the first time pair. If it is the first time pair, it gets processed under Y. Any other time pair gets stopped at N and doesn’t move to output table. In this way, we are ensuring that only one time pair will move to output table for further processing.

The first time pair will be modified with the “first clock in” and “last clock out” data and will be moved to output for further processing.

Below are the four possible scenarios that may happen.

Scenario 1: Both “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 0.0000 – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (0.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:

• The start time of the time pair is deleted using FILLPB-
• The start of record type (P10) is deleted using FILLPF
• The no. of hours is reduced to 0.0000 using FILLPN

Then the value of the “last clock out” time type ZVB6 (0.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0.           Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:

• The end time of the time pair is deleted using FILLPE-
• The end of record type (P20) is deleted using FILLPG
• The status of the time pair is changed to 1 using FILLP11 implying that both start and end times are missing from the time pair
• The time pair is moved to output table for further processing using COLOP *.
• Hence, the time pair has both “From” time and “To” time as blank.

Scenario 2: “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 0.0000 and 18.0000 respectively – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (0.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:

• The start time of the time pair is deleted using FILLPB-
• The start of record type (P10) is deleted using FILLPF
• The no. of hours is reduced to 0.0000 using FILLPN

Then the value of the “last clock out” time type ZVB6 (18.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:

• The end time of the time pair is filled with value of “last clock out” time type ZVB6 (18.0000) using FILLPE.
• The end of record type (P20) is added to time pair using FILLPG
• The status of the time pair is changed to 2 using FILLP12 implying that clock in time is missing from time pair.
• The time pair is moved to output table for further processing using COLOP *.
• Hence, the time pair has “From” time and “To” time as blank and 18.0000 respectively.

Scenario 3: “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 08.0000 and 0.0000 respectively – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (08.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:

• The start time of the time pair is set from “first clock in” time type ZVB5 using FILLPB.
• The start of record type (P10) is set for time pair using FILLPFP10.

Then the value of the “last clock out” time type ZVB6 (0.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is not greater than 0, the processing happens under *. Below things happen for the first time pair:

• The end time of the time pair is deleted using FILLPE-
• The end of record type (P20) is deleted using FILLPG
• The no. of hours is reduced to 0.0000 using FILLPN
• The status of the time pair is changed to 3 using FILLP13 implying that clock out time is missing from time pair.
• The time pair is moved to output table for further processing using COLOP *.
• Hence, the time pair has “From” time and “To” time as 08.0000 and blank respectively.

Scenario 4:  “First Clock In” (ZVB5) and “Last Clock Out” (ZVB6) have value as 08.0000 and 18.0000 – The first time pair moves for processing under Y. The value of “first clock in” time type ZVB5 (08.0000) is read using HRS=DZVB5 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:

• The start time of the time pair is set from “first clock in” time type ZVB5 using FILLPB.
• The start of record type (P10) is set for time pair using FILLPFP10.

Then the value of the “last clock out” time type ZVB6 (18.0000) is read using HRS=DZVB6 and then compared with 0 using HRS?0. Since the result is greater than 0, the processing happens under >. Below things happen for the first time pair:

• The end time of the time pair is set from “last clock out” time type ZVB6 (18.0000) using FILLPE.
• The end of record type (P20) is set for time pair using FILLPGP20.
• The status of the time pair is changed to 0 using FILLP10 implying that the pair is error free with both start time and end time.
• The time pair is moved to output table for further processing using COLOP *.
• Hence, the time pair has “From” time and “To” time as 08.0000 and 18.0000 respectively.

The next step is to include these PCRs ZVB4, ZVB5, ZVB6, ZVB7 and ZVB9 in positive time management schema.

A custom schema ZTCN is created by copying from standard time schema TM00 – Time Evaluation with Personnel Time Events.

Below is a screenshot of the custom time schema ZTCN.

The PCRs ZVB4, ZVB5, ZVB6, ZVB7 and ZVB9 are included in time schema ZTCN as per the sequence shown in the above screenshot.

PCRs ZVB4, ZVB5 and ZVB9 are being processed by function PTIP because TIP table is being processed in these PCRs. Par 2 is GEN because it is called for all time types.

PCRs ZVB6 and ZVB7 are being processed by function ACTIO because TIP table is not being processed in these PCRs.

I have included function PRINT after PCRs ZVB4 and ZVB5 to print table TES to display the value of time types ZVB1, ZVB2, ZVB3 and ZVB4 which get generated in these PCRs.

In the same way, I have included function PRINT after PCRs ZVB6 and ZVB7 to print table TES to display the value of time types ZVB5 and ZVB6 which get generated in these PCRs.

I tested around 22 different scenarios for this solution and all the scenarios passed with the desired result.

Please refer the below screenshots for the results.

I will now pick up some scenarios from the 22 scenarios that I tested and show how the time events got processed in system.

Testing Scenario 1:

IT2011

P2011

Table TES

Final Pair Formed

Time Evaluation Result – It fails since last clock out is missing.

Testing Scenario 2:

IT2011

P2011

Table TES

Final Pair Formed

Time Evaluation Result – It fails since first clock in is missing.

Testing Scenario 3:

IT2011

P2011

Table TES

Final Pair Formation

Time Evaluation Result – It fails since last clock out is missing

Testing Scenario 4:

IT2011

P2011

Table TES

Final Pair Formation

Time Evaluation Result – It is successful.

Here I come to the end of this knowledge artifact. Thank you for your patience for going through this document. I hope this knowledge artifact has been beneficial for you.

Warm regards,

Vivek Barnwal,

vianshu@gmail.com

Hi,
I posted this document in my non-SCN blog and it seems some people find it quite useful. So, I thought SCN members, particularly HR technical people, might find it useful as well:

For objects in OM (as indeed for other PD-modules like Training and Events Management, Qualifications, etc.) you can easily capture texts in several languages. But you need to be aware of the concepts behind it, most notably, when you design custom developments for OM in a multi-lingual environment

Capturing texts for all objects in all languages the system is used in can be quite an effort, so many organisations choose to be selective about which languages are used for which parts of the organisational structure. E.g. you might decide that:

• everything needs to be available in English
• all orgunits and jobs need to be available in the language the corporate HQ
  is using, say, for the sake of the argument, in Spanish
• and data in other local languages are only used for the objects used in that
  particular country

So, if everybody is following these rules (and we strongly recommend to define and communicate these rules as part of your global template), it can already be difficult enough, but then you can be sure that sometimes there will be an orgunit in, say, Germany, which hasn't been translated into English or Spanish.

SAP provides a good tool to manage this problem. In table T778L, you can define, in which sequence the system should look for data, if it can't be found in the logon language:

So, in this example, if you are logged in in Japanese and some orgunit you are seeing on the screen doesn't have a Japanese description, the system will show it in English instead. If English is not available, it will show it in Spanish, and so on. So, the SAP standard deals quite well with this issue, but how about your custom programs?

Most developers follow the best practise of selecting language dependant content using the logon language of the user (available in system table as SYLANGU) and many think that this is enough. However, it is not necessarily. As shown above, a user might be logged on in a language where there is no text available and in this case, to be as good as SAP standard, you'd need to select using the language sequence of T778L. Failing to observe the language issue might not only lead to objects displayed with no description text. It might even lead to omitting whole orgunits from your report.

If you use a simple statement like
"SELECT * FROM HRP1000 WHERE ... and LANGU = SY-LANGU"
then you would miss any orgunits in the system, which are only captured in other languages completely and without any hint something might go wrong. Imagine your CEO running a global headcount report and missing a whole country, because its top orgunit doesn't have its text translated into English!  Therefore, to be really clean, you should always select without using a language key first and then use the language sequence to determine the right description. Or make sure the SAP function modules or methods you are using are doing this for you.

Of course, there may be bespoke circumstances in your organisation allowing for a simpler solution. It might be the case that you know for sure your org management is always going to be there in English only. In that case, you can go for a simpler solution. In that case, you might not even use SY-LANGU, but rather hard code the selection on "EN" to make sure anybody, who happens to log in with a different language, would still get a result.

You create or maintain a process by transaction PEST; A simple example which will be used throughout this article is the following:

In this model, the unique root node is the German payroll driver RPCALCD0. It constitutes the first step of this process model. In the second and third step, payslips are printed by the RPCEDTD0, and payroll accounts are generated by the RPCKTOD0. In other words, the node "Payroll" has two children, namely the nodes for RPCEDTD0 and RPCKTOD0, respectively. One also says that these two nodes have the "Payroll" node as a parent. Note that an e-mail notification will be sent after the execution of RPCEDTD0. This is indicated by the symbol in the upper right corner of the corresponding box. Associated with this model is the selection program H99_SELECT_PERNR.

A process model is executed via the HR Process Workbench which can be called by transaction PUST. The following diagram illustrates the program flow of a process in its simplest form:

With transaction SWEL you can monitor all events that have been raised by a process model. In our example the event trace looks as follows:

After these preparations, we are now in a position to collect some hints how to debug the above steps of a process model.

• How to debug the selection program:
  1. Create a process in transaction PUST.
  2. Start this process by pressing F8.
  3. Choose "Immediately" on the upcoming pop-up.
  4. On the selection screen of the report, fill in the data, enter "/h" in the command field, press Enter, and execute the program.
     

From now on, we assume throughout that a process has already been carried out by transaction PUST.

• How to debug the reports along with their variants used during a process:
  1. In transaction PUST, right-click on the number of the process you want to analyze. Go to "Display additional information" and keep in mind the starting time of this process.
  2. Start transaction SM37. Enter WF-BATCH as user name and choose the time appropriately around the starting time of the process. You obtain a list containing the jobs executed during the process. If you want to debug one of this jobs, mark the job in question, enter JDBG in the command field, and press Enter.
      

• How to debug a single step of a process:
  1. Set a breakpoint in method DETERMINE_SUPPLIED_OBJECTS of class CL_HR_PM_PW_PROCESS_PROG at line 47 for the command  CALL METHOD me->modify_parcel_objects.
  2. Go to transaction SE37, choose HRPY_PROCESS_WORK_ON_EVENT as  function module, and press F8 (Test/Execute).
  3. In the following screen click on "Debugging".
  4. Press "Save" on the two upcoming pop-ups without entering anything.
  5. Press F7. After that, you are at the coding of HRPY_PROCESS_WORK_ON_EVENT.
  6. Press F6.
  7. Change the values of the variables H52SPS-PROCESSID, H52SPS-STEPID, EVT_NAME, P_CONT as follows:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-PROCESSID	0000000001 for the first step, 0000000002 for the second step, etc.
     EVT_NAME	JOB_STARTED
     P_CONT	X

  8. At the breakpoint jump to the next statement by putting the cursor on the next statement in line 51 and choose "Goto Statement" in the "Debugger" menu. (Otherwise, the system recognizes that this step has already been performed and proceeds in a different way.)
  9. Note that the job generated by the function module is no longer planned by user WF-BATCH, but by the user who started the function module.

• How to debug all children of a process step. This also enables you to monitor how the STEP_ENDED event is raised:
  1. Proceed similarly as for the first step, but at point 7. choose the appropriate values for the parent node:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-STEPID	the step ID of the parent node
     H52SPS-RUNID	the run ID of a finished run of the parent node from transaction PUST, e.g. 0000000001 for the first run
     H52SPS-PARAID	e.g. 000001
     EVT_NAME	JOB_ENDED
     P_CONT	X

• How to debug the communication such as e-mail notifications after a step has ended:
  1. Go to transaction SE37, choose HRPY_PROCESS_COMMUNI_ON_EVENT as  function module, and press F8 (Test/Execute).
  2. In the following screen click on "Debugging".
  3. Press "Save" on the two upcoming pop-ups without entering anything.
  4. Press F6.
  5. Change the values of the variables H52SPS-PROCESSID, H52SPS-STEPID, EVT_NAME, P_CONT as follows:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-STEPID	step ID from PUST for the step you want to monitor, e.g. 0000000001

Sometimes during the project implementation you find you change a program or do customizing in a table but system does not request any new change request. This means your program / table is already included into another open(not released) request.

In this case if you would separate your changes and send them into other servers(Q and P) you must take them out from other request and make your own request. For this you can do:

1. Create a request thru SE01. Choose the same type of request which your changes are included. (Customizing / Workbench and so on)

2- Right-mouse click on your request and choose "Include Objecs...".  Now you can include the other request and then delete not required objects and just keep your own objects.

     2.1 Otherwise you have to find the key of object one by one and add them. In this case double click on original request and in "Objects" tab you have object key in columns "Program ID", "Object Type" and "Object Name". You must copy all of them and past into your request.

Now if the question is which request includes my changes it's simple to find it. If you have a program go into SE38 and open it(display) or if you have a table go, for example thru SE11 and display it. Then in "Utilities" menu choose "Versions > Version management".

Here you will find the request name(number)

Hope this help functional consultants in this issue because having information about request structure and handling issues are important for a functional consultant.

Omid

Many users are not aware of this issue, although it's been around for some time:

Deriving a dependant cost item from a direct cost item in an earlier period doesn't work, if the cost object (e.g. employee) has changed its org unit since that period. Example: you have a business rule saying that the Xmas bonus paid in December equals x percent of the base salary plus overtime payments paid in September. This is easy to configure with standard configuration. No BAdI needed. However, If the employee has changed orgunit in October, this doesn't work. The bonus will be calculated as zero.

This is due to the fundamental design of the planning run, which is running per org unit rather than per employee / cost object. Therefore, you can't even deal with this issue using custom programming in the planning run BAdI.

We've been dealing with this by creating dummy cost items in the data collection BAdI, which are moved into the target period, where they can be used as calculation basis. When several cost items are affected, we also found it handy, to have these things configurable rather than all hard coded in the BAdI. No custom table needed - you can create a "dummy" planning context instead to hold the config for the dummy cost items. A quick and easy solution.

However: like everything done in data collection, it can't respond to any changes made in detail planning. So, in these cases a manual correction would still be necessary.

It would be interesting to know, who is aware of the problem, whom it is really bothering, and which solutions you may have found, particularly for detail planning. Please share your experience here.

A solution by SAP doesn't seem to be planned. The issue is merely documented in note 888780, but the suggested "solution" is to make corrections manually. This could affect large numbers of employees and it's also some effort to find out, who's affected. So, not an acceptable solution in my book. Maybe it would help, if more customers are aware of the issue and push SAP for a solution either directly or through their respective user groups.

This document was generated from the following discussion: The specified item was not found.

SuccessFactors Employee Central Payroll supports the following 23 countries:

• Australia
• Austria
• Brazil
• Canada
• Chile
• China
• Denmark
• Finland
• France
• Hong Kong
• India
• Ireland
• Italy
• Japan
• Malaysia
• Mexico
• Netherlands
• Russia
• Singapore
• Spain
• Sweden
• United Kingdom
• United States

This is a collection of the most useful SuccessFactors resources: documents, blogs, reports, and videos. This includes links that will cover an introduction to SuccessFactors, the acquisition by SAP, SAP's strategy, the BizX suite, integration, and other related documents and resources.

Overview

SAPexperts in-depth Special Report: SAP and SuccessFactors - An Overview (SAPexperts)

SuccessFactors with SAP ERP HCM - SAP PRESS Bookstore (SAP PRESS)

Market, Customer, and Consultant-related

SAP and SuccessFactors – Staying Informed

SuccessFactors named Market Leader in Six IDC Reports (SuccessFactors)

Magic Quadrant for Talent Management Suites 2013 (Gartner)

How to Transition from an SAP HCM to a SuccessFactors Consultant

SuccessFactors and SAP HCM consulting: The Wild West of 2013

The Future of SAP HCM and SuccessFactors Consulting - 2013 : CloudAve (Cloud Avenue)

Future of SAP HCM [podcast] (SAP HCM Insights Podcast)

The state of Talent Management in SAP HCM and Impact of SuccessFactors - With Thomas Otter [podcast] (SAP HCM Insights Podcast)

SAP and SuccessFactors - Mobility, Innovation, Payroll and Charity

SuccessFactors, The Future of SAP HCM Consulting, Project Execution, Training and more! [podcast] (SAP HCM Insights Podcast)

Cloud: When & Why Whitepaper (SuccessFactors)

Business Execution for Dummies (SuccessFactors)

SAP Forum: Life after Lars [diginomica.com]

Impact of DevOps and Cloud on SAP and ERP System Administrators (YouTube)

How significant is SAP’s on-premise and Cloud licensing swap announcement?

Solutions

SAP Jam – SAP Help Portal Page (help.sap.com)

SAP Jam Administrator Guide [PDF]

SuccessFactors Onboarding: Taking a Fresh Approach to Employee Engagement and Retention              ... (SuccessFactors)

Calibrate Employee Performance Through SuccessFactors [registration required] (SAPexperts)

SuccessFactors Employee Central Time Off - Made for You! - YouTube (YouTube)

SuccessFactors LMS vs SAP LSO – Some observations | NTT DATA Business Solutions | Australia (NTT Data Solutions)

Comparison Between SAP ERP HCM E-Recruiting and SuccessFactors Recruiting [registration required] (SAPexperts)

SuccessFactors Workforce Analytics or SAP Business Intelligence for Human Resources?

Solutions: Employee Central

Employee Central handbooks from SAP [s-user required]

What’s New in SuccessFactors 1302 release for Employee Central, Platform and Admin Tools

Implementing SuccessFactors Employee Central with a SAP background

SAP HANA Cloud Platform: Turbocharge SuccessFactors Applications (YouTube)

Eat like never before: SAP Networking Lunch

Manage Mass Changes in SuccessFactors Employee Central [registration required] (SAPexperts)

Solutions: Employee Central Payroll

Employee Central handbooks from SAP [s-user required]

SuccessFactors Employee Central Payroll - list of supported countries

New SAP and SuccessFactors Cloud Payroll Offering

EPI-USE Announces Its SAP-Qualified EPI-USE U.S./U.K./Australia Payroll Rapid-Deployment Solutions for SuccessFactors Employee Central Payroll | SuccessFactors (SuccessFactors)

Technical, data model, and configuration

Mapping SAP OM objects to SuccessFactors For a Hybrid Model

SuccessFactors: The X Factor of Data Models

Employee Central Entities and Interfacing

Extending SuccessFactors with the Metadata Framework

Rules and Picklists in the SuccessFactors Metadata Framework

Integration Strategy

SAP and SuccessFactors talent hybrid model: what lies ahead, plus a few small hidden jewels

SAP HCM and SuccessFactors Integration Packages: an overview

The Real Truth about SAP and SuccessFactors Integration

SAP and SuccessFactors - "Proven" Integration is Hype

Integration and Integration Packages

SAP HCM and SuccessFactors Integration Packages: an overview

Integration Add-on 1.0 for SAP HCM and SuccessFactors

Integration Add-on 1.0 for SAP HCM and SuccessFactors: Support Package 2

Integration Add-on 2.0 for SAP HCM and SuccessFactors

Integration add-on 2.0 for SAP ERP HCM and SuccessFactors BizX – SAP Help Portal Page (help.sap.com)

Integration Packages Administration Guide on SAP Service Marketplace [S-user required]

Pilot Test of the Integration add-on for SAP ERP HCM & SuccessFactors BizX

Integration Q&A: Managing employee compensation using SAP HCM and SuccessFactors

Integration Q&A: Real-World Impressions on SAP and SuccessFactors Integration Add-On’s

SAP HCM and SuccessFactors Biz X Employee Basic Data Integration RDS Demo - YouTube (YouTube)

SAP HCM and SuccessFactors Biz X Compensation Integration RDS Demo - YouTube (YouTube)

Employee Central – Employee Mini-Master Add-on Available

Dell Boomi AtomSphere for SuccessFactors (Dell Boomi)

How to integrate SuccessFactors talent data into SAP NetWeaver Business Warehouse?

SAP Jam ABAP Integration - Configuration Guide for SP Level 5

SAP Jam ABAP Integration - Configuration Guide for SP Level 6

LSO-to-SuccessFactors LMS RDS | hyperCision, Inc. [HyperCision]

PI Configuration Example (NWPI 1.0 SP2-4 & 2.0 SP0) [S-user required]

PI Configuration Example (NWPI 1.0 SP6 & 2.0 SP2) [S-user required]

Tips and Tricks

Tip: Creating a single URL for logging directly into SuccessFactors BizX demo instance

Single Sign-On to SuccessFactors from SAP HCM

Acquisition by SAP and Roadmap

Thoughts on SuccessFactors, Holiday Wish Lists for SAP HCM, and UNICEF [podcast] (SAP HCM Insights Podcast)

SAP and SuccessFactors Acquisition Q&A (Cloud Avenue)

News Analysis: SAP Buys SuccessFactors for $3.4B Signals SAP's Commitment To Cloud, HCM, and Social (Constellation Research)

SAP to Buy Into Software as a Service With SuccessFactors Deal [PDF] (Garnter)

SAP To Buy SuccessFactors: Major Shift In Talent Management Market (updated) (Bersin by Deloitte)

SAP and SuccessFactors Roadmap Analysis (Cloud Avenue)

SAP and SuccessFactors HCM Roadmap - With Amy Thistle [podcast] (SAP HCM Insights Podcast)

This report will show the data of given date ranges.

The report is created using dynamic internal table creation.

The Main Program

***********************************************************************
* Description:This program will read the payroll results and display  *
* them on ALV report.It will also compare the salary data               *
*  between the provided date ranges                                                   *
***********************************************************************
REPORT  zhrpy01.
***********************************************************************
* INCLUDES                                                                                             *
***********************************************************************
"---Include for all types and data
INCLUDE zhrpy01_top.
"---Include for selection screen
INCLUDE zhrpy01_screen.
"---Include for class and methods
INCLUDE zhrpy01_class.
"---Include for PBO
INCLUDE zhrpy01_pbo.
"---Include for PAI
INCLUDE zhrpy01_pai.
*&--------------------------------------------------------------------*
*& INITIALIZATION
*&--------------------------------------------------------------------*
INITIALIZATION.
"--initialize default data
CREATE OBJECT o_sal_comp.
*&--------------------------------------------------------------------*
*& AT SELECTION SCREEN
*&--------------------------------------------------------------------*
AT SELECTION-SCREEN.
IF o_sal_comp IS NOT BOUND.
CREATE OBJECT o_sal_comp.
ENDIF.
*---Validate screen
o_sal_comp->m_validate_screen( ).
*&--------------------------------------------------------------------*
*& START OF SELECTION
*&--------------------------------------------------------------------*
START-OF-SELECTION.
*&--------------------------------------------------------------------*
*& Build field catalog first and than  create dynamic table
*&--------------------------------------------------------------------*
o_sal_comp->m_build_field_catalog( ).
CLEAR it_saldata.
*&--------------------------------------------------------------------*
*& GET PERNR
*&--------------------------------------------------------------------*
GET pernr.
UNASSIGN <x_empdata>.
APPEND INITIAL LINE TO it_empdata ASSIGNING <x_empdata>.
IF <x_empdata> IS ASSIGNED.
*&--------------------------------------------------------------------*
* Get Action details
rp-provide-from-last p0000 space s_date-low s_date-high.
IF pnp-sw-found = c_1 AND p0000-stat2 = c_3.

*&--------------------------------------------------------------------*
* Get organnization details
rp-provide-from-last p0001 space s_date-low s_date-high.
IF pnp-sw-found = c_1.
*&---PERNR
<x_empdata>-pernr = p0001-pernr.
*&---Employee Name
<x_empdata>-ename = p0001-ename.
*&---Cost Center
<x_empdata>-kostl = p0001-kostl.
*&---Department
<x_empdata>-zzdept1 = p0001-zzdept1.
*&---Section
<x_empdata>-btrtl = p0001-btrtl.
*&---Grade
<x_empdata>-persk = p0001-persk.
*&---SBU
<x_empdata>-zzsbu1 = p0001-zzsbu1.
*&---Segment
<x_empdata>-zzseg1 = p0001-zzseg1.
*&---Payroll Area
<x_empdata>-abkrs = p0001-abkrs.
ENDIF.
*&--------------------------------------------------------------------*
* Get Bank details
rp-provide-from-last p0009 space s_date-low s_date-high.
IF pnp-sw-found = c_1.
*&---Bank Key
<x_empdata>-bankl = p0009-bankl.
*&---Account Number
<x_empdata>-bankn = p0009-bankn.
ENDIF.
*&--------------------------------------------------------------------*
* Get Dates
rp-provide-from-last p0041 space s_date-low s_date-high.
IF pnp-sw-found = c_1.
CLEAR :gv_dar,gv_dat.
*&---------------------------------------------------------------------*
*& Do loop to check for hire date or original hire date
DO 12 TIMES VARYING gv_dar FROM p0041-dar01 NEXT
p0041-dar02
VARYING gv_dat FROM p0041-dat01 NEXT
p0041-dat02.
*&---------------------------------------------------------------------*
*& Check for Original date
IF gv_dar = c_92.
<x_empdata>-jdate = gv_dat.
*&---------------------------------------------------------------------*
*& Check for hire date
ELSEIF gv_dar = c_95.
<x_empdata>-rdate = gv_dat.
ENDIF.
CLEAR: gv_dar, gv_dat.
ENDDO.
ENDIF.
ENDIF.
*&---------------------------------------------------------------------*
*& Get Salary Details
*&---------------------------------------------------------------------*

*& Reading of the Payresult for all the Periods
CLEAR: it_rgdir,it_rgdir_tmp,gv_relid,gv_type, gv_typename,
ref_payresult, gv_molga, gv_type_1,gv_tadir.

*&---------------------------------------------------------------------*
* Get Sequence numbers
CALL FUNCTION 'CU_READ_RGDIR'
EXPORTING
persnr          = pernr-pernr
TABLES
in_rgdir        = it_rgdir
EXCEPTIONS
no_record_found = 1
OTHERS          = 2.
IF sy-subrc = 0.
*&---------------------------------------------------------------------*
*PYXX_GET_RELID_FROM_PERNR
CALL FUNCTION 'PYXX_GET_RELID_FROM_PERNR'
EXPORTING
employee                    = pernr-pernr
IMPORTING
relid                       = gv_relid
molga                       = gv_molga
EXCEPTIONS
error_reading_infotype_0001 = 1
error_reading_molga         = 2
error_reading_relid         = 3
OTHERS                      = 4.
IF sy-subrc NE 0.
ENDIF.
*&---------------------------------------------------------------------*
*Verify the relid
SELECT SINGLE typename
FROM t52relid
INTO gv_type
WHERE relid EQ gv_relid
AND tabname = 'PCL2'.
IF sy-subrc NE 0.
gv_relid = 'IN'.
gv_type = 'PAYIN_RESULT'.
ENDIF.
gv_typename = gv_type.
CREATE DATA ref_payresult TYPE (gv_typename).
ASSIGN ref_payresult->* TO <x_payresult>.
*      SRTZA--Status Of records.
*      SRTZA = 'A' --Current Result.
*      DELETE it_rgdir WHERE srtza NE 'A'.
* PAYTY --> Payment Type ( Regular or Bonus)
* PAYTY =  SPACE --'Regular Payroll'.
* PAYTY = 'B'   --> 'Bonus'.
*&---------------------------------------------------------------------*
*Get Payroll Result
IF it_rgdir IS NOT INITIAL.
it_rgdir_tmp = it_rgdir.
SORT it_rgdir_tmp BY seqnr DESCENDING.
LOOP AT it_monthrange ASSIGNING <x_monthrange> WHERE type  = c_s.
LOOP AT it_rgdir_tmp INTO wa_rgdir WHERE abkrs IN pnpabkrs
AND srtza = 'A'
AND fpbeg <= <x_monthrange>-endda
AND fpend >= <x_monthrange>-begda .
CALL FUNCTION 'PYXX_READ_PAYROLL_RESULT'
EXPORTING
clusterid                    = gv_relid
employeenumber               = pernr-pernr
sequencenumber               = wa_rgdir-seqnr
CHANGING
payroll_result               = <x_payresult>
EXCEPTIONS
illegal_isocode_or_clusterid = 1
error_generating_import      = 2
import_mismatch_error        = 3
subpool_dir_full             = 4
no_read_authority            = 5
no_record_found              = 6
versions_do_not_match        = 7
error_reading_archive        = 8
error_reading_relid          = 9
OTHERS                       = 10.
IF sy-subrc EQ 0.
ASSIGN COMPONENT 'INTER-RT'
OF STRUCTURE <x_payresult> TO <x_rt>.
LOOP AT <x_rt> INTO wa_rt.
UNASSIGN <x_saldata>.
APPEND INITIAL LINE TO it_saldata ASSIGNING <x_saldata>.
IF <x_saldata> IS ASSIGNED.
<x_saldata>-pernr = pernr-pernr.
<x_saldata>-lgart = wa_rt-lgart.
<x_saldata>-betrg = wa_rt-betrg.
<x_saldata>-pabrj = <x_monthrange>-pabrj.
<x_saldata>-pabrp = <x_monthrange>-pabrp.
<x_saldata>-begda = <x_monthrange>-begda.
<x_saldata>-endda = <x_monthrange>-endda.
<x_saldata>-payty = wa_rgdir-payty.
CONCATENATE c_s <x_monthrange>-monthnm <x_monthrange>-begda+0(4)
INTO <x_saldata>-month.
ENDIF.
ENDLOOP.
ENDIF.
ENDLOOP.
ENDLOOP.
*&---------------------------------------------------------------------*
*If Comparison to be made
IF s_cdate IS NOT INITIAL.
LOOP AT it_monthrange ASSIGNING <x_monthrange> WHERE type  = c_c.
CLEAR : wa_rgdir,wa_rt,<x_rt>,<x_payresult>.

LOOP AT it_rgdir_tmp INTO wa_rgdir WHERE abkrs IN pnpabkrs
AND srtza = 'A'
AND fpbeg <= <x_monthrange>-endda
AND fpend >= <x_monthrange>-begda .
CALL FUNCTION 'PYXX_READ_PAYROLL_RESULT'
EXPORTING
clusterid                    = gv_relid
employeenumber               = pernr-pernr
sequencenumber               = wa_rgdir-seqnr
CHANGING
payroll_result               = <x_payresult>
EXCEPTIONS
illegal_isocode_or_clusterid = 1
error_generating_import      = 2
import_mismatch_error        = 3
subpool_dir_full             = 4
no_read_authority            = 5
no_record_found              = 6
versions_do_not_match        = 7
error_reading_archive        = 8
error_reading_relid          = 9
OTHERS                       = 10.
IF sy-subrc EQ 0.
UNASSIGN <x_rt>.
ASSIGN COMPONENT 'INTER-RT'
OF STRUCTURE <x_payresult> TO <x_rt>.
LOOP AT <x_rt> INTO wa_rt.
UNASSIGN <x_saldata>.
APPEND INITIAL LINE TO it_saldata ASSIGNING <x_saldata>.
IF <x_saldata> IS ASSIGNED.
<x_saldata>-pernr = pernr-pernr.
<x_saldata>-lgart = wa_rt-lgart.
<x_saldata>-betrg = wa_rt-betrg.
<x_saldata>-pabrj = <x_monthrange>-pabrj.
<x_saldata>-pabrp = <x_monthrange>-pabrp.
<x_saldata>-begda = <x_monthrange>-begda.
<x_saldata>-endda = <x_monthrange>-endda.
<x_saldata>-payty = wa_rgdir-payty.
CONCATENATE c_c <x_monthrange>-monthnm <x_monthrange>-begda+0(4)
INTO <x_saldata>-month.

ENDIF.
ENDLOOP.
ENDIF.
ENDLOOP.
ENDLOOP.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
*&--------------------------------------------------------------------*
*& END OF SELECTION
*&--------------------------------------------------------------------*
END-OF-SELECTION.
IF it_saldata  IS NOT INITIAL.
CLEAR: it_wagedata.
o_sal_comp->m_get_wage_data( ).
o_sal_comp->m_populate_final_table( ).
IF <x_final> IS ASSIGNED.
o_sal_comp->m_display_data( ).
ELSE.
MESSAGE text-054  TYPE c_e.
ENDIF.
ENDIF.