Payroll processing - Calculate average 6 month Basic Salary

I. Requirement

     There is a quite complicated requirement: calculate average 6 month Basic Salary for employee. For example: in Jun, average basic salary will be computed from Jan, Feb, Mar, Apr, May and Jun. but in Jul: start month from Feb until Jul. The most difficult here: how can system can store value from period to period, move corresponding to current period and no issue when having any retroactive accounting.

II. Solution   

     In order to resolve the request, you have to be clear how payroll processing with some table: IT, OT, etc and Functions and Operations as well. It's quite take time to explain very detail about it. So please investigate SAP documents for some Functions: PIT, operations ADDWT, AMT, etc in T-code PDSY. It's not too much difficult but a lot efforts to control it. I assume that you understand the prerequisites above.
     My solution as below:
     1. Create 6 wage type ( index from 00, 01, 02, 03, 04, 05) to store basic salary.
     2. Keep in mind these logic
          - wt 00 only contains current basic salary
          - wt 01 only contains Last value of wt 00 (if it's NULL, ONLY in golive period or 1st period running payroll, using current basic salary or Avg 6mon Basic Golive inputted manually)
          - the same logic will be applied for others from wt 03, wt 04 and wt 05.
     3. After having value in these wage types, you just simply total and divide 6. It's very easy so I don't care about it. I will focus only the step 2.
1. Configuration Wage type: Create 6 wage types (sharing same configurations in V_512W_D) and please note processing class 6:


2. PCR
     There are some PCR will re-produce solution steps mentioned in step 2:


     There are total 5 PCR (from ZV20 to ZV24). Basic Salary is wt 1000 and Avg 6mon Basic Golive is wt 5901.
     In the first PCR, there are some steps I would like to explain in order to be easier to understand
          - Output wt 1000 from internal table IT to output table OT to process. Insert current AMT into wt 00 (wt 8000). (100% fits with 1st step above Keep in mind these logic)
          - Get last value of wt 00 (wt 8000), if it's > 0, assign to wt 01 (wt 8001).
               Otherwise (Only in golive period or 1st period running payroll), check Avg 6mon Basic Golive.
               If Avg 6mon Basic Golive = 0, get Basic Salary and assign to wt 01 (wt 8001). Else wt 01 (wt 8001) equals Avg 6mon Basic Golive.
3. Schema
     Should include your PCR before processing class 10 in sub-schema XAL9 Factoring and storage. With my case I insert it into sub-schema XAP9 Import additional payments/deductions. I captured payroll schema when running display mode, as it's very important way to deeply and fast control and understand Payroll Schema

III. Testing

     Look at employee who has a complicated basic salary.

     And Avg 6mon Basic Golive (if you don't input the wt, system will get from current basic salary in 1st period running payroll )

     Now running Payroll in 1st period - Jan and Jun.
     In JANUARY: (6 wt (00 -> 05) contain correctly values: wt 00 (wt 8000) - current basic 300, other Avg 6mon Basic Golive 150.

     In JUNE: (6 wt (00 -> 05) are exactly: wt 00 (wt 8000) - current basic Jun 400, wt 01 (wt 8001) - basic in May: 400, wt 02 (wt 8002) - basic in Apr: 350, wt 03 (wt 8003) - basic in Mar: 400, wt 04 and wt 05 (wt 8004 & wt 8005) both base in Jan and Feb - 300).

Carry Forward Absence Quota

I. Purpose

     One of common and complex request involving Absence Quota is carry forward from current year to next year. There are many concerns and questions posted to find appropriate solution. Thus in this document I will give you a good solution and step by step how to CARRY FORWARD absence quota. Basing on my document, you will be more easier to adapt SAP Time Management to meet your customer's expectation.

     However, there are some basic information I have already mentioned in another documents, such as: grouping Personnel Structure (EE group and EE subgroup), Enterprise Structure (Personnel Area and Personnel Sub-Area), Grouping for Time Recording and the way to generate absence quota by using Time Type, so I will not re-write it again. Please look at link Absence Quota basing on Working Date.

II. Requirement

     Here it's the customer's expectation involving Absence Quota Type 20 - Sick Leave that should be implemented in their system:

          1. Yearly Absence Quota is 30 days.

          2. Generate 2.5 days (30/12) per month for employee at the last date of month.

          3. Start available: Hiring date or 1st Jan. End available: end of year 31st Dec.

          4. If remaining >= 10 days in this year, 10 days will be carried forward to next year.

III. Solution

     First of all, you have to create 2 Time Type and overview purpose as below

     1. Time Type 9D50 will be stored value to generate Absence Quota. Whenever Time Type is not initial, Absence Quota in IT2006 will be created automatically when accomplishing run Time Evaluation PT60.

          9D50 will be generated in a customized PCR with logic below:

                    - plus 2.5 days (30/12)

                    - plus accumulated in Time Type 9WSL

                         => assign to Time Type 9WSL

                    - Clear 9WSL immediately (to be sure that duplication 9WSL will not happen).                                                                        

     2. Time Type 9WSL check whether remaining Absence Quota bigger or equal 10 or not? If it's exactly, number 10 will be inserted into Time Type 9WSL and 9WSL is a bridge to bring this value from current year to next year.

          Note: create Time Type 9WSL 1 time per year, after accomplish generated Absence Quota on 31st Dec. So 9WSL exists only from 31st Dec to end of Jan next year. Why? because whenever last of month is coming, 9D50 will be inputted value and 9WSL will be blank So from Feb to Dec, 9WSL always equals 0.

     These are important points. From now steps by steps in configuration V_T559L and Time Schema also will be mentioned here.

1. Grouping

     As mention at the beginning, the Grouping I will use here: EE: 2, PA: 09 and Time Recording: 01.

2.Constant and Time Type

     2.1. ZPLEL Yearly absence quota is 30, it's maintained in V_T511K

     2.2. Time Type 9D50

     It's only used 1 time per month so it's configuration is really simple. Just save as day balance.

     2.3. Time Type 9WSL

     As you can see the purpose of 9WSL, storing value on last day of year and bring to next year, so you have to configure as picture below:

Activate "Transfer previous year". Without choosing this function, whenever 1st Jan comes, value in 9WSL will be blank. It means value calculated on 31st Dec will not carried to the day after - 1st Jan.

3. Configure in V_T559L

     With grouping above, there are steps for configuring in Table view Automatic Absence Quota Generation.

     3.1. Base Entitlement tab: of course it's will be assigned to Time Type 9D50.

     3.2. Transfer tab: it's important tab. Specifies the time at which the accrual entitlements are transferred to the Absence Quotas infotype (2006) to be made available for deduction. As the absence quota has to created monthly (at the last day of every month), so "Per time Evaluation Period" is necessary.

     If you choose "Per calendar year", assuming that from Jan - Nov, employee has 2.5 days Sick Leave every month, but when you open IT2006 in PA20, you cannot see Sick Leave. Why? because Transfer time to IT2006 is Calendar year, it's only transfer value in Time Type 9D50 to IT2006 on 31st Dec.

     Co-operation with Validity/deduction interval in index 3.3. It will help us accumulate Absence Quota monthly into yearly.

    3.3. Validity/deduction interval

     As mention in 3.2, both of them will create Absence Quota monthly but accumulate yearly

     Transfer time is monthly, so whenever 9D50 is not blank, Absence Quota will be generated in IT2006 with period is:

          Begin Date : Calendar Year (Start) => normally it's hiring date in 1st year, and 1st Jan from second year.

          End date: Calendar Year (End) => always 31st Dec.

    Deduction Period:

          Begin Date : Start of validity interval: it's Calendar year (chosen last step): => hiring date or 1st Jan.

          End date: End of validity interval: it's Calendar year => always 31st Dec.

     For example: employee joined company on 1st-Oct-2011

          in Oct-2011, employee has 2.5 days in 9D50, in IT2006: 1 record:

               Start 01.10.2011 - end 31.12.2011, Number 2.5, deduction: Start 01.10.2011 - end 31.12.2011.

          next month Nov-2011:

               just update record above:

               Start 01.10.2011 - end 31.12.2011, Number 5.0, deduction: Start 01.10.2011 - end 31.12.2011.

          in Dec-2011

               Start 01.10.2011 - end 31.12.2011, Number 7.5, deduction: Start 01.10.2011 - end 31.12.2011.

    3.4. Other tabs aren't important so only sharing:

4. Time Schema and PCR

    4.1. Time schema ZW04:

    Copy new Schema from TM04 and insert new schema with structure below:

     NOTE: you have to insert PCRs in order as same as I have done here.

     The logic already explained in this picture. Only call PCR ZW6C (creating Time Type 9D50) for generating Sick Leave Quota If EOM is true

     CUMBT: update value of time type in database.

     QUOTA: update absence quota and create new / modify records in IT2006.

     Next, check 31st Dec by ZI51, it's correct, ZW51 will be call to update value for Time Type 9WSL. After that CUMBT must be call again.

     4.2: PCR ZW6C

    

	HRS=CZPLEL	Get value ZPLEL in V_T511K, it's 30.
	HRS/12	Divide 12, current value is 2.5
	HRS+M9WSL	Plus Accumulate value of 9WSL into HRS.
	ADDDB9D50Z	Add into Time Type 9D50
	HRS=0	HRS = 0
	ADDMB9WSLZ	Clear 9WSL

        4.3: PCR ZI51

    

     4.4. PCR ZW51

    

	HRS=FR20C	Get Absence Quota left with subtype 20 in IT2006
	HRS?10	Comparing with 10
	*	>=
	HRS=10	HRS=10
	ADDDB9WSLZ	Assign to 9WZL to carry forward
	<	<
	LEAVE

     That's all Next part is testing to be sure that solution is correct

IV. Testing

     Hiring employee on May-2011

     Running PT60 until 31st May 2011, 2.5 Absence Quota with period from 01.05.2011 to 31.12.2011

     => It's correct

    

     Running PT60 until 31st Dec 2011, 20 days (from May to Dec: 8 months) Absence Quota with period from 01.05.2011 to 31.12.2011

     => It's correct

     Running PT60 until 31st Jan 2012, 12.5 days (10 days in 2011 and 2.5 days in Jan 2012) Absence Quota with period from 01.01.2012 to 31.12.2012

     => ALL is correct

Note: Another solution is using UPDTQA** (update Absence Quota directly, not use Time Type). You can follow my explanations in thread

Validity Period for SAP HR Enterprise and Employee Structure

I've seen this mentioned a few times, but having written this up, I thought some of you might find it usefull to have a more comprehensive description os this new feature, which I personally - as someone working a a few multi-country set-ups - belief is really cause for serious celebrations. Thank you Customer Connection Program!
If your organisation has been using SAP HCM for, say, 10 or 20 years, you'll know this problem all too well, particularly if your organisation is spread over a large number of countries:
The list of personnel (sub)areas and employee (sub)groups gets longer and longer and there is no easy way of making sure users don't pick obsolete objects, because none of them comes with time dependency or a validity period.
This has now changed with SAP note 1883014. SAP offers now the option to use validity periods for the 4 organisational objects mentioned above. This validity period acts as a constraint for what can be captured in personnel actions and infotypes 0001, 1008 and 1013, and cleans up the list when you hit "F4".
Once the required support package has been applied, you can easily activate the new feature in table T77S0, entry ADMIN - DELIM:

Note:

• As with most entries in T77S0, you'll get a warning message saying this is an entry in the SAP namespace. Don't worry: it is meant to be changed by the customer and SAP doesn't plan to overwrite it.
• No need to worry about not being able to use any org objects any more once you activate this feature. Existing org objects won't have any entry in the validity period tables yet, but, by default, a validity from 01/01/1800 to 31/12/9999 is assumed.

The first change you'll notice after the activation is that the objects feature a validity period in entry helps now:

So, let's assume we want to create a new personnel subarea "Cardiff" valid only from 01/01/2014. You create it by copying an existing one and renaming it as you would normally do. Then you find the configuration for validity periods in the IMG via: Enterprise Structure > Assignment > Human Resources > Validity Period for Organisational Assignments and add a new entry for Cardiff:

If we try to change the current record for an active employee starting at 01/07/2013, we see the same result as above, because the new subarea isn't valid yet:

However, if we create a new record in infotype 0001 starting after 01/01/2014, we find Cardiff in the list of options:

The same logic applies to personnel areas, employee groups and employee subgroups. We consider this a very helpful improvement to increase efficiency, avoid user frustration and improve data quality in SAP HCM. We definitely recommend implementing it, so you can get rid of old entries from all four tables in day-to-day business. Particularly in large global organisations, the lack of such a validity period has always caused problems in the long run.

There are a few points to be considered in the business process:

• This is not a full time dependency feature. These are only validity periods, which are checked against in the most important screens. The objects can only be made valid or unvalid, but they can't change their names or properties over time. E.g., you can't change the name of personnel subarea 0002 from "Edinburgh" to "Scotland" from, say, 01/01/2015. If you change the name, the new name will apply retro-actively for the full validity period of the object.
• When you create a new organisational assignment in infotype 0001, the last record always needs to extend all the way to 31/12/9999. So, you may have to create a record including employee groups or personnel subareas, which are valid at the start of the record, but not at the end. The system will allow this, but produces a warning message, so you know you'll have to change the org assignment later:
  
  
  
• You can also run a consistency check with program RP_PAD_CHECK_ORG_ASSIGN to show where organisational re-assignments are required due to validity periods ending:
  
• You would usually not want to adjust infotype 0001 data for employees who have left the organisation already. Over time, many leavers will have personnel (sub)areas and employee (sub)groups outside their respective validity areas in the infotype 0001 record of the inactive period and that's usually no problem. Therefore, the check against the validity period is not performed for leavers.

Some technical notes:

• SAP note 1883014 can't be applied with the note assistant: it's got to come via HR support package SAPK-60467INSAPHRRXX
• It is recommended to apply SAP notes 1882986, 1881595 and 1882972 together with the main correction. The first two notes are included in the same support package anyway, but 1882972 may have to be applied separately to fix a documentation error
• To eliminate errors in employee groups and subroups in transaction PA40 (personnel actions), SAP note 1949191 must be applied. It is not included in the same support package.

LSMW for OM Objects (org. unit, positions, jobs)

Hi Friends,

I want share some knowledge regarding how to upload the OM Objects like jobs, positions & Org. units through LSMW with batch input recording.

I know everyone is well versed with this LSMW, just consider it as a quick reference and step-wise document for who doing for the first time LSMW for OM Objects.

Pre-requisites:

We have to create all the OM Objects External Number range before uploading the objects through LSMW. Because system will not consider for Internal number ranges while recordings.

T-code: OONR

Creating Project / Subproject and Object:

Go to Tcode- LSMW

Click on Create button and give the name of the Project, Subproject and Object as desired

*Give Project names as SMALL otherwise while assigning upload file at step 7 Specify files, error will come. System path is not allowed more than 45 words (this is standard by the system)

Press Enter

Recording: Sample recording of Objects

1. In menu bar, Goto Recordings

Now click on Create Recording and give the Recording name and description

System will ask for Transaction code, give PP02

Maintain the fields that are mandatory, to create object types

Save the Record and click the button Back

Now system will show the recording results in the screen Create Recording

Click the Button Default All to default the system for Technical fields which are entered while recording

Save the screen and go back our Recording was completed

Once again go back to the LSMW screen and Execute the Project

Now, we have to do step by step LSMW (14 steps)

Step 1: Maintain Object Attributes

Select this radio button and click on executeà (Do same for other steps)

Now, click on Display/ Change icon (do this for every step, because by default it will be display mode)

Here, we are telling system that what kind recording should take into consideration while performing upload.

Select ‘Batch Input Recording’ and give name as shown below

Save and back

Step 2: Maintain Source Structures

Source structures are helpful in building hierarchical relationships. While uploading the data system always checks highest level structure first before going for subordinate structure.

1. Select source structure and createà
2. Enter details as shown belowà

Save and go back

Step 3: Maintain Source Fields

Here we assign all the fields which need to upload to source structure.

1. Click on Object Overviewà select tableà

Copy the fields and length in excel sheet (for temporary)

Note: exclude TABNAME and TCODE which are not required to maintain separately, system will take these from recording we made.

Make excel sheet as shown:

1. Now select ‘Maintain Source Fields’ button and execute
2. Click on ‘table maintenance

Paste from the excel sheet which we maintained.

* we can take either C or D for the Date format accordingly upload data has to be maintained

Save and go back

Step 4: Maintain Structure Relations

Here we check whether structure relations between legacy and R/3 established or not.

In this step there is no need to change, just save and come back.

Step 5: Display Field Mapping and Conversion

Here we establish the relationship between legacy and R/3 based on object fields.

In menu bar, go to Extrasà Auto Field Mapping

Note: Make sure that you select your recording before auto field mapping

Click on accept proposal for all the fields which want to upload

After auto field mapping complete, save and back.

Step 6: Maintain Fixed Values, Translations, User-Defined Routines

No need of this step-6

Step 7: Specify Files

In this step, you specify the location of the legacy file. The file in tabular form with first row field names

Now, double click on ‘Legacy Data – On the PC (Front End)

Save and go back

Example of Excel file to upload in the .TXT form

Step 8: Assign Files

Here, we just check whether file is assigned to source structure or not.

Save and go back

Step 9: Read Data

Here our legacy data is read

Execute Now, next screen shows how many number of records have been read

Step 10: Display Read Data

Here, we can display all for part of the data by giving line numbers

Check, whether data has been correctly fit into fields

Step 11: Convert Data

Here, whatever data has been read will convert to SAP standards.

Click on Execute button, it shows how many records have been converted. It should be same as data which have been read in step 9.

Step 12: Display Converted Data

Here, converted data can be viewed for cross check.

Data from the legacy file is fitting to correct fields, so we configured all prior steps without any mistake.

Note: If data is not fitting correctly, then we need to cross check Step3 and Step5.

Step 13: Create Batch Input Session

In this step, we create session for batch input

Make sure you check box for ‘Keep batch input folder’ is active

Step 14: Run Batch Input Session

Here we run the batch input session which we created in step 13.

Select Session and execute process

Here we can choose options, how upload should be done

It is recommendable that, first 3 to 4 records upload foreground to make sure data is uploading correct, for rest of records select ‘Display errors only.

Now legacy data will we upload to Master data of employees in SAP system.

Testing: whether objects are created or not

Table V_T527X (Org. units)

Table T528B (Positions)

Table T513 (Jobs)

For relationship LSMW:

Objects Relationships and Report RHINTE10