HRMS & Payroll Summary

Click here to load reader

  • date post

    24-Oct-2014
  • Category

    Documents

  • view

    463
  • download

    15

Embed Size (px)

Transcript of HRMS & Payroll Summary

Date Tracking in HRMS Payroll in Oracle

| Print |

Email

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 PAY_ELEMENT_TYPES_F Payroll Elements Description Firstly, we create some elements, which get created in table 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. 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

PAY_ELEMENT_LINKS_F - Payroll Element Links

PER_ALL_PEOPLE_F - Employee

record

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.

PER_ALL_ASSIGNMENTS_F Assignment table

PER_PERSON_TYPES - Person type

PAY_ELEMENT_ENTRIES_F

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

| Print |

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 .

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

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

| Print |

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 104332 100001

------------------N N

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

PER_ASSIGNMENT_EXTRA_INFO

HR_LOCATION_EXTRA_INFO PER_JOB_EXTRA_INFO PER_PEOPLE_EXTRA_INFO

Extra information for a location. Extra information for a job. Extra information for a person. Extra information for a position. Previous Jobs extra info

PER_POSITION_EXTRA_INFO PER_PREV_JOB_EXTRA_INFO

Stores extra information for an PAY_ELEMENT_TYPE_EXTRA_INFO element Extra information for a contact relationship. Documents of Record Information

PER_CONTACT_EXTRA_INFO_F

HR_DOCUMENT_EXTRA_INFO

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 ,v_info_type_name IN VARCHAR2 ,v_active_flag IN VARCHAR2 ,v_multi_row IN VARCHAR2

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;

HRMS Setups - NOT BR100

| Print |

Email

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 DFFs 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 EITs 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 oouchto capture if this guy sued your company, or to capture redundancy terms etc, or to capture negotiated notice periodblaah 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 & DFFs & 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 havent 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.

Special Information Types -SIT in HRMS Written by Anil Passi Wednesday, 15 November 2006

| Print |

Email

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

Audit Changes in Oracle HRMS 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.

| Print |

Email

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 [ _A ] will be moved into HRMS Audit Tables.

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