E-

Date Tracking in HRMS Payroll in Oracle | Print |

mail
Written by Anil Passi
Sunday, 10 December 2006
In this article, I will explain how the date-tracking works in Oracle HRMS. What is DateTracking in Oracle HRMS?
Let's take an example. An employee emails to their HRMS department that her Surname will change after 2weeks, as she gets married
after 2weeks.
Today being 10 December, HRMS team will Date-Track to 24-Dec-2006 and query on her record.
Next her record will be changed to reflect the Surname applicable from 24-Dec-Onwards.

How does Date-Tracking actually happens?

As soon as you logon to a screen which is based on Date sensitive information,
Oracle will prompt you with two options
1. Change the Effective Date of the current logged on SESSION
2. Retain the SYSDATE as Current Effective date

In reality, a record gets created/updated in a table called fnd_sessions.

If you click on YES, then you will get an opportunity to change the Current Session Date

OK, the Date Selected by user for date-track is stored in fnd_sessions with their sessionid. But how about application data?
When you attempt to modify a date-track sensitive data such as Person Surname, Oracle HRMS prompts you for either a Correct Mode or
Update Mode.

Lets say the record, before making the change the record was
Person First Name: Aish
Person First Name: Rai
effective_start_date : 10-JAN-2003 --when the person joined organization
effective_end_date : 31-12-4712 -- From Hr_Api.g_eot [end of time, well not literally]
If the record is modified in Correction mode, then this record will be modified as
Person First Name: Aish
Person First Name: Bachan
effective_start_date : 10-JAN-2003 --when the person joined organization
effective_end_date : 31-12-4712 -- From Hr_Api.g_eot [end of time, well not literally]

If the record is modified in UPDATE mode, then this record will be modified as
The existing record will be end dated
Person First Name: Aish
Person First Name: Rai
effective_start_date : 10-JAN-2003 --when the person joined organization
effective_end_date : 23-Dec-2006 -- a day prior to date-track date

A new record will be created

Person First Name: Aish
Person First Name: bachan
effective_start_date : 24-DEC2006 --when the person joined organization
effective_end_date : 31-12-4712 -- From Hr_Api.g_eot

Does this mean, when modifying in UPDATE mode existing record is end-dated and a new record is created?
Yes, indeed.

What are the other scenarios for the usage of Date-tracking?

1. Hiring an employee in future date.
2. Making salary changes which are effective after say 2months.

On a SQL*Plus session, I get nothing when I do select * from per_people_v?

Almost all the HRMS views on which screens are HRMS based, they have a join to fnd_sessions table.
When user changes their date-track value, it gets reflected in fnd_sessions table.
Use the SQL below to create a default record for your SQL*Plus session/
INSERT INTO fnd_sessions
(session_id
,effective_date)
(SELECT userenv('sessionid')
,SYSDATE
FROM dual
WHERE NOT EXISTS (SELECT 'c'
FROM fnd_sessions s1
WHERE userenv('sessionid') = s1.session_id));

What is the difference between quick-pay and payroll run?

Quickpay is a functionality(available from assignment screen), by which you can run the payroll for single person assignment. It uses the
same executable as that of actual Payroll run.

What is payroll run results?

As you would know, when payroll process runs, it reads the element entries for the assignment in pay_assignment_actions. For those
element entries, payroll engine either uses the entry value in "pay value" or it kicks off a fast formula if the element has a ff attached to
that. The end result is that each eligible element gets a result. These results are stored in pay run result tables.

What are the payroll run results tables?

Pay_run_results
Pay_run_result_values
Obviously the values are stored per element in Pay_run_results.
The input value used/derived by payroll engine is stored in Pay_run_result_values/
Which Assignment Records were included in Payroll Actions :- PAY_ASSIGNMENT_ACTIONS
pay_assignment_actions contains an entry for each Assignment_id that was eligible during Payroll Action.
For example if you run a quickpay, an entry for that specific assignment_id will be created in pay_assignment_actions.
Obviously this table has a column named assignment_id.
You can drill down from Assignment Action screen to view Payroll Run Results and Payroll Balances, for the specific assignment.
Hence both PAY_RUN_BALANCES and PAY_RUN_RESULTS reference ASSIGNMENT_ACTION_ID.
NOTE: ASSIGNMENT_ACTION_ID is the primary key of PAY_ASSIGNMENT_ACTIONS.
Also note that entries in this table are created by Concurrent Processes, hence this table is never updated by end user from screens. Hence
there is no date-tracking on this table.

Table Name Description

PAY_ELEMENT_TYPES_F – Payroll Firstly, we create some elements, which get created in table
Elements PAY_ELEMENT_TYPES_F. The primary key is a combination of
element_type_Id along with Date Track columns.
When will you join to pay_element_types_f ?
1. To display the name of Element in Reports
2. When payroll runs, the results are stored in PAY_RUN_RESULTS,
which stores a reference to element_type_Id.

PAY_ELEMENT_LINKS_F - Payroll
Element Links
PER_ALL_PEOPLE_F - Employee
To make payroll elements eligible to a group of people, you create
Element Links.
See Elements Basics article that explains why Element Links are
necessary.
The Primary key is ELEMENT_LINK_ID with date-track columns.
When will you commonly use element_link_Id ?
1. When querying on Element Entry[PAY_ELEMENT_ENTRIES_F],
a join can be made using ELEMENT_LINK_ID
2. The reason Oracle uses ELEMENT_LINK_ID in Element Entry to
work out Costing Segments based on Payroll Costing Hierarchy.
PER_ALL_PEOPLE_F - Employee record
record
PER_ALL_ASSIGNMENTS_F -
Assignment table
PER_PERSON_TYPES - Person type
It is well known that Employee records are stored in
PER_ALL_PEOPLE_F. Its a date track table with primary key being
person_Id. This table also has party_Id, because Oracle creates a party
in TCA as soon as a record in per_all_people_f gets created.
Main usage of per_all_people_f:-
1. To get the name of the person
2. To get the date of birth or tax Id of the person
Note:- The application uses PER_PEOPLE_F, as that is a secured view
layer on top of PER_ALL_PEOPLE_F
This is the most central table in Oracle Payroll. Payroll engine uses
this table as the main driver.
Why so: Because Element Entries are stored against Assignment
record.
This table is date-tracked, with primary key being assignment_Id
Usage of per_all_assignments_f?
1. Find position_Id, hence position, or grade, the organization for the
persons assignment.
2. It has foreign key to person_id. Each person Id can have no more
than one primary assignment at any given point in time.
3. Pay run results and also the pay_assignment actions refers to this
table.
This is the master table for Person Types. Some examples of Person
Types are Employees, Casuals, Applicants etc.
The primary key is person_type_id.
But please do not try joining this with person_type_id in
per_all_people_f.
Instead join that to per_person_type_usages_f
_x will give you person_type usage as of SYSDATE.
For any other date, use the classic p_date between effective_start_date
and effective_end_date.
PAY_ELEMENT_ENTRIES_F These two tables are inserted into when fresh Element Entries are
created.
PAY_ELEMENT_ENTRIES_F
Each Element that gets attached to an Assignment will have an entry in
PAY_ELEMENT_ENTRIES_F.
For each assignment you will have one or more records in
PAY_ELEMENT_ENTRIES_F table.
It is logical that PAY_ELEMENT_ENTRIES_F has following
columns
Assignment_id
Element_link_id
ELEMENT_TYPE_ID
This table is date-tracked too. Please do not ask my where there was a
need to store both ELEMENT_TYPE_ID and also
ELEMENT_LINK_ID in this table.
Just storing the ELEMENT_LINK_ID could suffice. However, i guess
Oracle did so for Performance reasons.
PAY_ELEMENT_ENTRY_VALUES_F This table stores a reference to PAY_ELEMENT_ENTRIES_F. In
plain English, this table captures the entry value for the elements.
The Input Value is stored in SCREEN_ENTRY_VALUE. The name
suggests that it stores the Formatted Screen value. However, I can
assure you that SCREEN_ENTRY_VALUE stores the non formatted
value. For example screen might showHH:MM as 03:30, but
SCREEN_ENTRY_VALUE will have 3.5
This table is date-tracked, and its primary key is INPUT_VALUE_ID.
Where can I commonly join INPUT_VALUE_ID to ?
To the payroll run results value table, i.e.
PAY_RUN_RESULT_VALUES
You can also join to PAY_COSTS, if you wish to work out which
input value contributed to a specific Payroll Costed Amount.
PAY_PAYROLL_ACTIONS Well, just about anything you make the Oracle Payroll engine do, it
records an entry in PAY_PAYROLL_ACTIONS.

What are the possible actions?

To name a few:-
Costing
Quickpay
Payroll Run
Magnetic Transfer [synonym to EOY-End of Year run]
Transfer to GL......etc
A column named ACTION_TYPE [validated by lookup type
ACTION_TYPE] is used to store the type of action.
Migrate Special Information Types in HRMS | Print |
Written by Anil Passi
Wednesday, 15 November 2006
In this article, I will explain how to migrate Special Information Types into Oracle HRMS using API.

Before I jump to give the script for migration of SIT, let me first explain the background so that you are able to troubleshoot the errors
yourself during the data migration into oracle's special information types.

Question: How is the special information types configured?

Answer: A dedicated article has been written to explain the background and setup details for Special Information Types. This migration
example uses the SIT created in article as linked here .

Question: I find the special information type tables confusing. Please can you explain?
Answer : The combination of Segments is stored in table per_analysis_criteria.
This combination is identified by analysis_criteria_id.
Next in table per_person_analyses, analysis_criteria_id is linked to the Person Id.
Effectively, this means that a given combination of segments can be assigned to various Person Records. This is fundamental to the nature
of Key Flex Fields. This will get clearer at the very end of this article.

Question: Give me the example of the SIT, to which we will migrate values.
Answer: For this training exercise, we will assume following SIT exists in Oracle Apps.
SIT Name : XX Medical History Of Person
SIT Fields:
Medical Condition(Segment1)
Year of illness (Segment2)
Cured Now Flag [Yes/No] (Segment3)
Note: We configured & created this SIT in article as linked here .
Let’s migrate this data against the PERSON_ID which we migrated in Article(link here for Person Migration Article ).
Person Id = 134593 was created as a result of that migration.

Run, the below SQL, to migrate SIT Data

DECLARE
v_count INTEGER := 0;
n_object_version_number INTEGER;
n_analysis_criteria_id INTEGER;
n_person_analysis_id INTEGER;
n_pea_object_version_number INTEGER;
n_id_flex_num INTEGER;

BEGIN
SELECT fi.id_flex_num
INTO n_id_flex_num
FROM fnd_id_flex_structures_vl fi
WHERE (fi.id_flex_structure_code = 'XX Medical History of Person')
AND (application_id = 800)
AND (id_flex_code = 'PEA');

LOOP
BEGIN
---reset the variables here
n_object_version_number := NULL;
n_analysis_criteria_id := NULL;
n_person_analysis_id := NULL;
n_pea_object_version_number := NULL;

hr_sit_api.create_sit(p_person_id => 134593

,p_business_group_id => fnd_profile.VALUE('PER_BUSINESS_GROUP_ID')
,p_id_flex_num => n_id_flex_num
 ,p_effective_date => SYSDATE
,p_date_from => SYSDATE
,p_date_to => NULL
,p_segment1 => 'Influenza'
,p_segment2 => '2000'
,p_segment3 => 'Y'
,p_analysis_criteria_id => n_analysis_criteria_id
,p_person_analysis_id => n_person_analysis_id
,p_pea_object_version_number => n_pea_object_version_number);
dbms_output.put_line('Migrated SIT with n_analysis_criteria_id=>' ||
n_analysis_criteria_id);

v_count := v_count + 1;
IF MOD(v_count
,50) = 0
THEN
--do a commit for each 50 records during migration
COMMIT;
END IF;
EXCEPTION
WHEN OTHERS THEN
--need to log error here
dbms_output.put_line('Exception ' || SQLERRM);
/* xx_error(p_migration_type => 'MIGRATION TYPE'
,p_error_message => SQLERRM
,p_resolution => 'Enter details manually'
,p_person_id => 134593);
*/
END;
EXIT; --in this case just one record
END LOOP;
 COMMIT;
END;

Read further, if you love digging into the details...

Here is our SIT data, after migration, as seen from the screen.
Here are the values that we migrated against SIT in the Oracle HRMS tables.
SELECT fi.id_flex_num,
FROM fnd_id_flex_structures_vl fi
WHERE (fi.id_flex_structure_code = 'XX Medical History of Person')
AND (application_id = 800)
AND (id_flex_code = 'PEA');
=======Returns=======
ID_FLEX_NUM : 50522

SELECT analysis_criteria_id, segment1, segment2, segment3

FROM per_analysis_criteria
WHERE id_flex_num = 50522
=======RETURNS=======
ANALYSIS_CRITERIA_ID : 311542
SEGMENT1 : Influenza
SEGMENT2 : 2000
SEGMENT3 : Y

SELECT * FROM per_person_analyses WHERE person_id = 134593

=======RETURNS=======
ANALYSIS_CRITERIA_ID : 311542 --Note the same value as in previous SQL

Note that the combination of Medical Condition, Illness Year & Cured Flag is not directly attached to the PERSON_ID. Hence, if another
of your employee was to have exactly the same medical illness, on the same date, and is also cured....then oracle will not create a new
record in table per_analysis_criteria, as Oracle Flexfield Engine will reuse this combination of codes for other employee. Effectively the
same principles apply to gl_code_combinations & code_combination_id.
 | Print |
Differences between EIT and SIT in HRMS
Written by Anil Passi
Thursday, 22 February 2007
The main difference between Special Information Types and Extra Information Types is that SIT is KeyFlexfield whereas EIT is
Descriptive Flexfield.

What does this mean for your implementation?

In the context of SIT being KFF, you attach a combination of attribute values to a Person Record.
Let's take an example.
Say we have a requirement to capture two fields against a Person
Field 1 :- Smoker Yes/No
Field 2:- Colour Blind Yes/No

In case of SIT, assuming there are two non-smokers and neither of those are colour blind, then there will be just one record in
table PER_ANALYSIS_CRITERIA
Segment1 = N
Segment2 = N
ANALYSIS_CRITERIA_ID=1000

For both these people, their respective SIT records in PER_PERSON_ANALYSES will reference
"ANALYSIS_CRITERIA_ID=1000"
Think of this like CODE_COMBINATION_ID in GL_CODE_COMBINATIONS, and compare that to
PER_ANALYSIS_CRITERIA

However in case of EIT, assuming same example as above, two physical records will be created in table
PER_PEOPLE_EXTRA_INFO

PERSON_ID PERSON_EXTRA_INFO_ID PEI_INFORMATION1 PEI_INFORMATION2

----------- ------------------------ ------------------- --------------------
104332 100000 N N
104332 100001 N N

Should my decision be based upon saving space in the database, so that records can be reused in case of SIT?
Not really, space is hardly an issue these days in ERP systems, few bytes here or there make no difference at all to database sizing.
However there are other differences that can be considered in making this decision.

Updates made to SIT's are less efficient

In this example, if a person were to become a Smoker from non-Smoker, then, when you update persons SIT record, Oracle will query
PER_ANALYSIS_CRITERIA to check if a combination of Y[smoker] and N[Colour Blind] already exists in that table. If such record
combination is not found, then Oracle will create such combination in PER_ANALYSIS_CRITERIA. Following that record creation,
PER_PERSON_ANALYSES will be updated to reflect the new ANALYSIS_CRITERIA_ID for Y & N combination.
However in case of EIT, Oracle would have to merely update the PER_PEOPLE_EXTRA_INFO table.

During implementation, when deciding between EIT and SIT, should I ask myself a question that- how often will Extra
Information be modified?
Indeed, given that columns segment1, segment2.....segment30 in PER_ANALYSIS_CRITERIA are not usually indexed [unlike in
gl_code_combinations]

At what Levels do EIT work?

TABLE_NAME DESCRIPTION

Extra information for an

PER_ASSIGNMENT_EXTRA_INFO assignment.
 Extra information for a
HR_LOCATION_EXTRA_INFO location.

PER_JOB_EXTRA_INFO Extra information for a job.

PER_PEOPLE_EXTRA_INFO Extra information for a person.

Extra information for a

PER_POSITION_EXTRA_INFO position.

PER_PREV_JOB_EXTRA_INFO Previous Jobs extra info

Stores extra information for an

PAY_ELEMENT_TYPE_EXTRA_INFO element

Extra information for a contact

PER_CONTACT_EXTRA_INFO_F relationship.

Documents of Record
HR_DOCUMENT_EXTRA_INFO Information

However in case of SIT's, those are usually defined at Person Level [although these SIT can be enabled at Job/Position level too].

PER_PERSON_ANALYSES table has date_from and date_to. Does this mean a SIT Combination for a person can be end-dated?
Correct, you can implement a date-track kind-of model with SIT [not true date-tracking though, as inactive record are displayed in screen
too]
However in case of EIT, in order to implement a similar logic for date ranges, you will have to use PEI_INFORMATION1 to capture
DATE_FROM, and use PEI_INFORMATION2 to capture DATE_TO

However Security model of SIT differ from that of EIT?

The security model of EIT is more advanced than SIT.
If an SIT is made available to responsibility via Taskflow, then all the Special Information Type Contexts[ SIT KFF Contexts] will be
available to the user.
See link Basics of Special Information Types to see the steps for defining and enabling SITs in Oracle HRMS.

Security of EIT is a two step process

Step 1 for EIT Security :- Register EIT for its usage in a specific Legislation Code
To make an EIT visible for a given Legislation, a record must be entered in EIT registration table for LegislationCode & EIT
combination[see the pl/sql procedure at the bottom of this article to see list of those table]. Instead of executing the procedure below, you
may decide to run concurrent program "Register Extra Information Types (EITs)"
Step 2 for EIT Security :- Make the registered EIT available to specific Responsibility using screen "Information Type Security"
PL/SQL Code in case you wish to register EIT using SQL
CREATE OR REPLACE PROCEDURE register_type(v_table_name IN VARCHAR2
,v_info_type_name IN VARCHAR2
,v_active_flag IN VARCHAR2
,v_multi_row IN VARCHAR2
 ,v_desc IN VARCHAR2
,v_leg_code IN VARCHAR2) IS
BEGIN
--
IF v_table_name = 'PER_PEOPLE_INFO_TYPES'
THEN
--
INSERT INTO per_people_info_types
(information_type
,active_inactive_flag
,multiple_occurences_flag
,description
,legislation_code
,object_version_number)
VALUES
(v_info_type_name
,v_active_flag
,v_multi_row
,v_desc
,v_leg_code
,1);
--
ELSIF v_table_name = 'PER_ASSIGNMENT_INFO_TYPES'
THEN
--
INSERT INTO per_assignment_info_types
(information_type
,active_inactive_flag
,multiple_occurences_flag
,description
,legislation_code
 ,object_version_number)
VALUES
(v_info_type_name
,v_active_flag
,v_multi_row
,v_desc
,v_leg_code
,1);
--
INSERT INTO per_assignment_info_types_tl
(information_type
,LANGUAGE
,source_lang
,description
,last_update_date
,last_updated_by
,last_update_login
,created_by
,creation_date)
SELECT m.information_type
,l.language_code
,b.language_code
,m.description
,m.last_update_date
,m.last_updated_by
,m.last_update_login
,m.created_by
,m.creation_date
FROM per_assignment_info_types m, fnd_languages l, fnd_languages b
WHERE m.information_type = v_info_type_name
AND l.installed_flag IN ('I', 'B')
 AND b.installed_flag = 'B'
AND NOT EXISTS (SELECT '1'
FROM per_assignment_info_types_tl pait
WHERE pait.information_type = m.information_type
AND pait.LANGUAGE = l.language_code);
--
ELSIF v_table_name = 'PER_POSITION_INFO_TYPES'
THEN
--
INSERT INTO per_position_info_types
(information_type
,active_inactive_flag
,multiple_occurences_flag
,description
,legislation_code
,object_version_number)
VALUES
(v_info_type_name
,v_active_flag
,v_multi_row
,v_desc
,v_leg_code
,1);
--
ELSIF v_table_name = 'HR_LOCATION_INFO_TYPES'
THEN
--
INSERT INTO hr_location_info_types
(information_type
,active_inactive_flag
,multiple_occurences_flag
 ,description
,legislation_code
,object_version_number)
VALUES
(v_info_type_name
,v_active_flag
,v_multi_row
,v_desc
,v_leg_code
,1);
--
ELSIF v_table_name = 'PER_JOB_INFO_TYPES'
THEN
--
INSERT INTO per_job_info_types
(information_type
,active_inactive_flag
,multiple_occurences_flag
,description
,legislation_code
,object_version_number)
VALUES
(v_info_type_name
,v_active_flag
,v_multi_row
,v_desc
,v_leg_code
,1);
--
ELSE
dbms_output.put_line('Error - user entered invalid or unsupported table name');
 RAISE value_error;
END IF;
--
END register_type;
/

exec register_type ('PER_ASSIGNMENT_INFO_TYPES', 'XX Smoker Etc Details[as defined in DFF Context]', 'Y', 'Y', 'Description of
your EIT', 'GB [your legislation code]');
commit;

E-
HRMS Setups - NOT BR100 | Print |
mail
Written by Anil Passi
Thursday, 30 November 2006
Please find the common setup steps that are required during almost all the Oracle HRMS Implementations. Please note that this is not a
BR100 document.
HRMS Key FlexFields
In any HRMS Implementation, you will be required to design your flexfields. Some of the important Key Flexfields are listed below.
Job Flexfield
Usually couple of segments max

Grade Flexfield
Normally used to work out Payscales
Position Flexfield

Cost Allocation Flexfield

This may not be used when using Labour Distribution module.
Different segments are made visible at different levels. For example you will hide the company segment against Element Entry.

People Group Flexfield

Special Information Types

Note on all HRMS KFF :- Usually you will have Dynamic insertion set to True for these flexfields.

HRMS Descriptive FlexFields

I am listing some common DFF’s configured in Oracle HRMS.
Additional Personal Details
Avoid using this, as you should leverage the Special Information Types. Use this DFF only when you want the details to be made visible
from the Main Employee screen.

Additional Assignment Details

Avoid using this, as you can use EIT’s against the Assignment. However, you can use this DFF when you want the details to be made
visible from the Main Assignment screen itself.

Additional Element Type Details

Use this DFF during Implementation, to cross reference the Element Codes [or their equivalent codes] from the legacy system. This will
help you during Payroll migration.

Add'l Period of Service Det's

Use this DFF when you wish to capture information against an employee when they are Terminated. For example “Legal Sue Flag”
oouch…to capture if this guy sued your company, or to capture redundancy terms etc, or to capture negotiated notice period…blaah

Additional Grade Details

You may have mapping grade codes in Legacy system tied into this DFF [because legacy system may not have had a Flexfield kind of
design]

Define Value sets and Lookup Codes to Support the KFF & DFF’s & Std Process
Some examples for Lookup Codes that you will define are:-
Employment category
Absence Reason

Define Person Types

You will do this almost in every implementation when doing Oracle HRMS setup. For example in Public sector Universities, a student
can become a tutor and hence be called Bursary. Every business has its own terminology when it comes to defining person types.

Common Notifications
Confirmation notification to an employee when their grade or salary details change
Notifications related to Stock / Share Options allocation etc

Define Company Locations

Define all the physical locations/addresses where employees can be working. This gets attached to the assignment record of the person.

Define your business group

For example “Go4gold Asset Management”
This is defined in the Organization screen itself,
You can define various defaults like Employee Number/Applicant Number Generation being Manual or Automatic. Also, here you will
attach the structure of all the Key Flexfields which you define in Step 1 of this document. Also the default Payroll currency gets attached
to the Business group.

Define your Organizations

You will always implement Organization Hierarchy in Oracle HRMS. Organizations are usually related to the Cost Centre.

Define Organisation Hierarchies

Relate the Organizations that you defined in previous step.

Define jobs
We defined the Job Flexfield in the beginning. Here we assign values to jobs.

Define grades
We defined the Grades Flexfield in the beginning. Here we assign values to grade

Define the responsibilities and Security Profiles [Also link the two]
You will not only be defining responsibilities, but you will also be securing the list of Employees that can be visible from those
responsibilities. For this security, you define something known as Security Profile
To give you an example of that, lets say that you want a Departmental head to be able to see list of Employees that work within his
Organization/sub-Organization. To achieve this you will define a security profile and will attach the Organization hierarchy to this
security profile[starting from his Organization node in hierarchy]
Security profiles can also filter employees on Grade etc. For example, for a responsibility named “HRMS CEO”, you only wish to display
employees that are Manager grades. Security profiles can also be created by attaching a filtering SQL to them.
Effectively, following items can help you build a security profile:-
Organisations / Organization Hierarchy
Positions
Payroll ( e.g. to restrict the viewable list of Employees by Monthly payroll)
argh ! this reminds me that we haven’t defined Payroll as yet.

Define Payroll
You will specify the periodic cycles of Payroll, i.e. Monthly, Weekly etc.
Not only that, some statutory information like Employers Tax Reference etc will be captured against the Payroll definition.
Optionally specify the suspense account, default costing account against the Payroll Definition.

Define Elements
This setup will be driven by your Payroll Requirement

Define Balances and Fast Formulas

Balances capture the running totals of Elements, for example Leave remaining Balance will be defined as “Total permission Holidays”
MINUS “Element Entry value for Days Off Taken” MINUS “Element Entry values for Comp Off”. Effectively, you will attach Elements
to a Balance. A balance will have dimensions like Yearly, Monthly etc. For example, Annual Leave balance will have YTD dimension.

E-
Special Information Types -SIT in HRMS | Print |
mail
Written by Anil Passi
Wednesday, 15 November 2006
In this article, I will explain in steps :- How to create special information types in Oracle HRMS.

Once you have learnt the fundamentals of SIT, you can then also reference the article on migrating special information types into Oracle.

Before we dive into the special information type creation example, let’s first do some questions and answers.

Question: What is so special about special information types?

Answer : Nothing is special about SIT !!, it happens to be a Key FlexField, effectively a combination of segment/field values get attached
to a person/hr record. In plain English, SIT is a mechanism by which you can create new fields, to capture additional information against
an HRMS record.

Question : Why use an SIT when we can enable descriptive flexfields against the person record.
Answer : Various reasons, as listed below:-
A. Data in Descriptive Flexfield against an employee record will be visible to all the users that have access to the Employee
creation/query screen.
On the contrary, using HR Workflow security, we can make SIT to become visible for the responsibility that we desire.
B. There is limited number of descriptive flex field columns available.
C. SIT let you logically group similar information together. For example, you may wish to capture "Medical illness history/details" and
also Citizenship/Country Residency History" of your employees. In this case, you will create two different SIT.

Question : So, can we create multiple Special Information Types?

Answer: Indeed, you can define as many contexts as you desire for special information type key Flexfield in Oracle Apps.

Question : What are the steps in brief for setting up an SIT

Answer:
Analysis of sit requirement, which includes
A. Find additional fields that are required for your HRMS screen, and can be logically grouped to be enterable from one window.
B. The validations that will be required against each of the SIT fields. Note: some people prefer to call them segments instead of fields.
Anyway, for these validations you will need to create value sets, or will have to find an existing value set that can be reused.
Implementation: of special information type
A. Configure the key Flexfield
B. Add segments to the key flex field
C. Assign value sets to segments. Skip this step if you want your key flexfled segment to be free text. Value sets are attached to each such
segment that requires validation.
D. In HRMS Superuser responsibility , enable the key flexfield context in screen "Define special information type"

Question : Give me the example of the SIT, to which we will migrate values.
Answer : For this training exercise, we will assume following SIT exists in Oracle Apps.
Sit name : "XX Medical History Of Person"
Sit Fields:
Medical Condition
Year of illness
Cured Flag (Yes/No)

Question: Show me the steps visually, using screenshots...

Answer: As below

First, go to Key Flexfield register screen and query to find the title of KFF. No changes are done in this screen,
Go to application developer responsibility, and click on menu key flexfield segment.

Query on the title in key flexfields segment screen.

Add a new context/structure to this flexfield.

The name of this context is "XX Medical History Of Person" in our example.
Click on segments, to add segments/fields for this special information type.
Add the three segments as below

Freeze the structure (structure ,means combination of these 3 segments)

Also, ensure the Dynamic Inserts are Checked(Turned On)
In HRMS responsibility , go to define special information types and create an entry for the context.

Now go to person record, by finding for the person that we migrated in earlier article .
Click on button labeled special Info
See the SIT in action here, finally
 E-
Audit Changes in Oracle HRMS | Print |
mail
Written by Anil Passi
Monday, 05 November 2007
To enable auditing in Oracle Human Resources is merely a 15minutes job.
Please find below, a step by step example that enables Auditing in Oracle HRMS.
This article is a proof of concept for auditing in Oracle HRMS, as it ends with showing the data from HR_AUDITS and
HR_AUDIT_COLUMNS.

Note that all the audit screens in System Administrator responsibility are located in Menu Path /Security/AuditTrail/Groups

Step 1. From system administrator, Enable Auditing for Oracle HRMS Application.
To do this, navigate to AuditTrail Install in System Administrator.
Next, query on Oracle Username HR and then enable the Audit Enabled check-box.
Step 2. From system administrator, Create a audit group that contains PER_ALL_PEOPLE_F
In this proof of concept, we will see how changes to First Name and Last name of a person are being audited.
Navigate to Audit Group screen in System Administrator, and create an "Audit Group" as show below.

Step 3. From System Administrator responsibility, add the desired columns that you wish to audit upon on table PER_ALL_PEOPLE_F
Step 4. Again in System Administrator, Run Concurrent program “AuditTrail Update Tables” as shown below.
Step 5. Next, login to HRMS Superuser and run concurrent program “Audit Trail Update Datetracked Tables”
This again is a one off step that must be implemented when you have made changes to Audit Groups/Tables/Column lists.

Step 6. Change the name of a person from Aneel to Anil, from person entry screen.
Step 7. Schedule the concurrent program “Audit Report” Oracle HRMS Superuser
In this example, I am passing it parameter PER_ALL_PEOPLE_F
By running the process “Audit Report”, data from shadow Audit tables [ <table_name>_A ] will be moved into HRMS Audit Tables.

Step 8. Next, query the data from HR_AUDITS and HR_AUDIT_COLUMNS