Plan Design Copy Process: The Missing Pieces

The plan design copy feature available in OAB is life saver. It really does make the setup
migration process a piece of cake. However, there are some things that it does not copy over and at times this can be a cause of concern. These are some of the things that I have found which were not copied over by the process

- People group criteria attached to eligibility / variable rate profiles
- Some of the coverage and rate rules defined at Enrollment Period for Plan
- Some of the formulas attached at Enrollment Period for Plan
- Life events triggers
- Life event Collapse rules
- Life events not attached to the program enrollment definition
- Eligibility criteria Enrolled in Another plan information
- Eligibility criteria Covered in Another plan information
- I am assuming most of the related coverage based eligibility criteria
- Communication type setup

Setting OAB Conversion Profile

Use the following steps to set up the profile to prevent life events from triggering in OAB. This should generally be used when converting HR Data

1. Log in to US Super HRMS Manager or US HRMS Manager responsibility
2. Navigate to Other Definitions > Action Parameters form
3. Create a new parameter group name called OAB Conversion (if OAB Conversion does not exist)
4. Add Data Migrator Mode parameter (DATA_MIGRATOR_MODE) and set it to ‘P’.
5. Save the changes.
6. Log in as Application Administrator
7. Navigate to System Profile Values form.
8. From the Find window, select User Name, enter your username, and enter profile option ‘HR:Action Parameter Group Name’. Hit the Find button.
9. Under your user name, select ‘OAB Conversion’.
10. Save the changes.

This profile can be set at any level, setting it to user level will ensure that the life events are triggering for other users when they are making changes.

COBRA Notification Letter

It is difficult to setup the COBRA Notification Letter correctly the first time. There is no comprehensive documentation around it which makes it all the more challenging. These are some of the things to keep in mind

1. The seeded report refers to the COBRA Beneficiary tables. If a COBRA beneficiary record is not created for a participant, the report will not work. On the Program > Participation Eligibility > Life Event form, ensure that the "Applies To" field is null for the COBRA Initial life event. This field should only be setup for life events, such as Divorce, Child Becomes Ineligible etc., that allow dependents to enroll as participant in the COBRA program.

2. Ensure that you have attached the COBRA and HIPAA regulation to the COBRA compensation objects

3. Ensure that you have created a COBRA reporting group and included all the COBRA compensation objects to it. Also attach the COBRA regulation to it.

4. Create an Organization for the Benefits Department and attach it to the COBRA Program. The Organization details are listed on the COBRA report generated by OAB. You should also specify the Organization Role (Name of the Person) and Organization Role Type as Administrator

This setup will ensure that the COBRA notification letter is correctly generated.

Are AME Rules combined as an ‘AND’ or an ‘OR’ clause?

A friend of mine recently asked this question and I thought it might make a good post. The question was, How does AME behave when you have setup multiples rules for a transaction type. How does the end approval hierarchy look in such a scenario and how do you control it.

In such cases the result depends on whether the various rules that you have configured are mutually exclusive or if more than one rule can be true for an transaction. For any transaction, AME evaluates all rules defined in the functional area and merges the out of all rules into a final approver lists according to an preset rule. So the answer to the question is that the rules will result in an AND. However, if the rules have conditions which ensures that only one rule applies for an transaction then the output results in an OR.

Many a time, you would need to code complicated attributes to achieve the OR conditions. Well if design the rules carefully the desired output can be achieved by using the Priority Processing Mode. AME allows you to define relative or absolute priorities for each of the rules. When the rules are evaluated, AME automatically collapses the rule as per priority settings and generates the end approval hierarchy as per your requirement.

What is Oracle BI and what is HRI?

Customers generally have a lot of confusion about what is Oracle BI and how is it different from HRI. Oracle Business Intelligence (BI) offering generally refers to tools that can be used for enterprises data warehouse such as Oracle Express, Discoverer, Siebel Analytics, Data Mining etc. This differs from the BI offering available with Oracle Applications including HR. There are various different reporting solutions available differntiated by the tech stacks on whcih they are built. Some of the common ones are

• DBI (Dashboard): New data warehousing solution with Dashboard developed using Performance Management Framework (PMF)
• Performance Management Viewer (PMV) Reports : Some BI reports and KPI delivered with iRec and HRI use this technology
• HRMSi (Discoverer): Discoverer based operational and strategic reports.
• Siebel Analytic Based reports (Not sure if they are available in R12)
• Embedded Data Warehouse (EDW): Old type of data warehousing solution with discoverer as the front end
• HTML Reports: Oracle Reports based intelligence reports (not available in R12).

As far as HR is concerned, HRI is generally considered as DBI. But is reality there is a lot more avaialbe with the product then just this. When you buy a HRI license you get tonnes of Discoverer reports (150+ workbooks) along with Discoverer ad hoc business areas which can be used to create Ad Hoc reports. There are also a lot of operational Discoverer reports available for which you do not need HRI license and are available with core HR/Payroll/OAB modules. The best way to distinguish if a Discoverer report is a HRI reports or a core module report is to look at the name of the report, all HRI reports start with HRMSi where as others would have BEN or PAY or HRMS.

DBI for HRMS Implementation Considerations

DBI for HRMS has a number of components that are either derived either directly from the HRMS or using custom logic defined by the implementation teams. In this blog I am trying to illustrate some of considerations for setting up the system

Headcount:
Headcount is the most important metric used in DBI for HRMS. It is used for calculating the employee count, turnover, averages and everything that has something to do with employee calculations. DBI determines headcount based on the following things

• Assignment Budget Value of Headcount specified on the employee assignment record (on assignment form go to others button and select budget)
• In case you don't have the ABV defined, DBI uses the seeded TEMPLATE_HEAD to calculate the headcount. The formula assigns 1 as headcount to everyone who does not have a ABV specified.
• In case your company have a different approach for calculating headcount, you can define the BUDGET_HEAD formula and assign custom headcount. This formula (with same name) has to be defined in every business group. In case where the BUDGET_HEAD formula is not defined for a business group Oracle would use the TEMPLATE_HEAD formula to determine the headcount. If you don't want to specify a different formula for each business group you can define the global formula in setup business group.
  

Salary:
Salary is another important data point from which the metrics such as average salary and total salary are derived. Some of the important things to take care of are

• DBI uses the salary information assigned on a person's assignment record. If you store salary information in any other place, DBI will not be able to pick it up.
• Because DBI uses annual salary, the salary basis on person's assignment should have an annualization factor. If the annualization factor is not available, DBI cannot determine the annual salary.
  

Supervisor Hierarchy:
DBI uses supervisor hierarchy for reporting purposes and for rolling up data. The hierarchy is created based on the supervisor assigned on person's assginment record. Many a time you would find that the hierarchy is not created correctly. Some of the reasons for this are

• No Supervisor: If a person does not have a supervisor, he is excluded from the hierarchy. So you would now have 1 less headcount. This situation should never exist as it leads to incorrect numbers in the portal
• Terminated Supervisor: Similar to no supervisor condition, with the only difference being that if the terminated supervisor happened to be a senior manager, you would find a significant amount of people missing from the hierarchy
• Supervisor Loops: Consider the scenario A reports to B, B to C and C to A. In such a situation, there is no top node for the hierarchy and it breaks the hierarchy. To determine the loops in your system, watch for the log file of the HRI Load All Supervisor Hierarchy process to see for the loops. You might have to set the profile, HRI: Enable Detailed Logging to get the required output.
  

Jobs:
Since very few companies have global jobs, aggregating data based on job can be very challenging. DBI simplifies this by allowing you to set up Job Function and Job Family dimensions for each job. Job Function can be considered as equivalent of dept
e.g. Sale, Marketing, Accounts, HR etc. Job Family is more detailed and can include specific job e.g Manager, Clerk etc. To setup Job Family and Job Function, DBI expects you to define equivalent segments on job kff or dff. You can associate the value set used for these
segments to the following profile options

HR: BIS Job Hierarchy - Job Group Level 1 (Job Family)
HR: BIS Job Hierarchy - Job Group Level 2 (Job Function)

Exclude People for Reports
There are situation when you want to exclude a specific set of people from DBI portlets e.g. Companies that have implemented contingent workers as employees with a user person type of Contingent Worker, do not want contingent workers to be included in reports. DBI allows you to define the HRI_MAP_WORKER_TYPE fast formula in the setup business group. Using this formula you can decide the people to excluded from portlets based on the combination of following properties

system_person_type
user_person_type
primary_flag
employment_category
assignment_type


Map Job Roles:
If you are implementing the Chief HR Officer page and want to have the HR to Staff ratio KPI, then you would need to map the jobs to determine the jobs that are assigned to HR Staff. Define the HRI_MAP_JOB_JOB_ROLE formula in the setup business group. The formula lets you to determine the HR jobs based on the combination of job family and job function. If you don't have job family and functions defined then you would not be able to use this formula.

Performance
Oracle HRMS allows you to perform performance reviews using the Performance Review functionality available in PUI or using the Appraisals available in SSHR. DBI collects data from both the sources, so you should not have any issues with whichever function that you use. However, the rating given on the reivew cannot be compared directly as they can carry different weightage based on the function or business group they are used with. DBI expects a normalized rating based on which various ratings can be compared. You can define the NORMALIZE_REVIEW_RATING or NORMALIZE_APPRISAL_RATING fast formulas to normalize the rating into 1 to 100 scale. DBI further classifies the normalized rating based on the seeded buckets which classifies the rating into high, medium and low.

How to clear Apache Cache without bouncing the listener

I know that everyone using Self-Service hates Apache Cache. Every time you assign yourself a new responsibility or you change a profile option or upload a new piece of code, you need to bounce the listener. Well here is a way to get around this without actually bouncing the apache server

1. Give yourself the "Functional Administrator" responsibility.
2. Once logged in to this responsibility click on the "Core Services" tab (top-right).
3. Click on the "Caching Framework" link in the blue menu bar.
4. Click on "Global Configuration" link in the left vertical menu.
5. In the "Cache Policy" region click on the "Clear All Cache" button.
6. Click the "Yes" button to confirm the action.
7. Click the "Apply" button to apply the changes.

This clears the Apache cache just like bouncing the Apache listener does, but no one is disconnected and you don't even need the DBA.

DBI for HRMS

DBI for HRMS delivers some extremely powerful dashboards and reports that help managers to take strategic decisions. It uses the data stored in HRMS table to build a data repository (similiar to data warehouse, except that data sits on the same server as the OLTP system). The repository is refreshed daily to provide managers with the latest enterprise level metrics.

What can you do with DBI

1. Contains Dashboards, KPI's and reports for enterprise level reporting
2. Allows users to look at headcount, turnover, new hires, transfers, salaries by various views such as supervisor, job function, job family, performance rating, length of service, geography etc.
3. Uses supervisor hierarchy, allowing managers to view data only for people reporting to them
4. Truly enterprise reporting solution. It does not use security profiles and business groups to restrict data
5. Comes with extensive drill down, slicing and dicing features
6. Allows users to drill down to detail of every transaction. (e.g. when viewing turnover, managers can look at terminated person's details)
7. Allows you to refresh the repository in full and incremental mode.
   

Difficulties in implementing DBI

Even though I was involved in the development of the module, there are a few situations that can complicate matters (grrr...)

1. Bad Data: DBI is extremely sensitive to data, any small issue with data will be magnified when reporting through DBI. Cleaning bad data can prove to be a big task when implementing DBI
2. Build Custom Reports: Even though oracle delivers tools to design your custom reports, but there are several limitations and would require extensive design and development effort. It would be just like any other BI project.
3. Extend delivered reports: If you want anything other then personalizing the reports and dashboards, its going to be difficult. My suggestion is don't even attempt it. DBI uses extremely complicated data structures and SQL's to present those number.
4. Hierarchies: DBI uses supervisor hierarchy, many of the customers might want to use either a position hierarchy or an organization hierarchy for reporting. Current version of dbi does not allow you to do that.
5. Debugging Issues: Debugging DBI issues can be complicated. Its best you call Oracle Support and seek the help of the development team (they are extremely helpful trust me..i used to be one of them :))
6. Handling Contingent Workers: If you are using the CWK person type creating contingent workers, you are ok. If you have contingent workers created as Employee be ready for some fun. Even though DBI delivers functionality to handle such situations, it going to take some effort to get the number correct.