ORACLE ADVANCED BENEFITS

11I-R12 DELTA
1
Jitty_George/Pranab_Majumdar
Last Updated On: 16-AUG-2012
ORACLE ADVANCED BENEFITS
R12.0 HRMS RUP3
Reopen Life Events Process
Open Enrollment Window Modification
Additional Input Parameters for Fast Formulas
R12.1 HRMS RUP1
Enforce Minimum Coverage for Life Events with No Electable Choices
Restrict Display of Primary Care Provider
Enhanced Individual Contribution Distribution
R12.1 HRMS RUP2
Use Default Enrollment to Reinstate Backed Out Intervening Events
Use a New System Profile to Carry Forward Certifications for Life Events
without a Configured Coverage Restriction
Recalculate Imputed Income When Coverage Amount Changes Upon Receipt of
Certification
Suppress HIPAA if Participant Gains Electability in Alternate Plan Type
2
ORACLE ADVANCED BENEFITS
R12.1.3
User Defined Criteria for Dependent Eligibility
Query Life event in Enrollement Window

R12.1 HRMS RUP5
Ability to use a person selection rule for System Extracts
Ability to disable a communication type
Provide a Not Eligible flag for compensation objects
Ability to attach eligibility to life events and communication types
Delete Unrestricted Life Event Enrolments
Enrollment Rate History in Self Service
Reopen Reinstated Enrollment
Close Enrollment When Elections Made in Self Service
3
R12.0 HRMS RUP3
4
5
REOPEN LIFE EVENTS PROCESS
Description Solution
In earlier version, in order to reopen an already
processed or closed Life event it was required to be
done manually, Eg: In case of AE if the customer
comes back with a new rate value for comp object,
the LE needs to be processed again, in such case it
had to be done manually for each participant.

Enrollment windows after reopening the
processed events cannot be modified.

This enhancement provides the benefits users
the flexibility to reopen a large volume of life
events as a batch. Using this one can reopen a
certain LE on huge group of population identified
by the criterion like organization, location, benefit
group etc.

In combination with the "OE Window
Modification" functionality, users can extend
enrollment windows after reopening the processed
events(discussed with Open enrollement window).

6
REOPEN LIFE EVENTS PROCESS
Process to reopen LE
7
OPEN ENROLLMENT WINDOW MODIFICATION
Description Solution
The earlier release did provide the flexibility to
modify an existing Enrollement Window's
Enrollment Period End Date, Processing End Date,
Default Enrollment Date, or Provide a Number of
Days Extension of any Life event once it is started.
There is now a concurrent process titled "Manage
Open Enrollement Window" which provides the
flexibility to modify an existing Open Enrollement
Window's Enrollement Period End Date,
Processing End Date, Default Enrollement Date, or
Provide a Number of Days Extension.
This can also be done in case of other Les
intervening with the Open event

8
OPEN ENROLLMENT WINDOW MODIFICATION
Process to modify Open
enrollement window
9
ADDITIONAL INPUT PARAMETERS FOR FAST FORMULAS

Description Solution

Till now Person_id was never passed as a
input value of fast formulas and it had to be
derived from the Assignment_id always. Due
to this

Person_id can now be easily passed as an
input value in Fast Formulas.
R12.1 HRMS RUP1
10
11
ENFORCE MINIMUM COVERAGE FOR LIFE EVENTS
Description Solution
There are situations that occur where due to either data
or configuration issues, that someone is found ineligible
for something in which they are currently enrolled and
end up with no enrolment . In these cases participant
loses coverage and is not allowed to make elections for
specific events. So if an event did not allow electable
choices, and a person was found ineligible, the event
closed with no error resulting in dropped coverage.
There was no way to evaluate the minimum plan type
requirements and raise an error if coverage is lost for an
eligible plan type during the run.
A new profile option BEN: Check Enrollment Limits has
been created that deals with such scenarios. This
determines if the application should execute the check
for minimum and maximum Plan Type in a Program when
an event is processed and the person cannot make
elections. When this profile is set to yes, if the minimum
maximum limit for a plan type is violated while
processing a life event type, you see an error message.

With this enhancement, the application performs the
following:
Identifies if the minimum enrollment for the Plan Type
in Program should be checked for a business group if an
event is processed and the person cannot make elections.
Checks if a person lost coverage, when you process an
event that does not allow the person to make elections.
Checks if a person still meets the Plan Type in Program
minimum limitation requirements, if the person lost
coverage and is still eligible for the Plan Type in Program
that they were enrolled in.
Generates an error if the requirements are not met so
the person does not lose coverage and the eligibility
issues can be resolved.
With dropped coverage recognized, benefit
administrators can take the appropriate steps to restore
coverage
12
ENHANCED INDIVIDUAL CONTRIBUTION DISTRIBUTION
New Profile
13
RESTRICT DISPLAY OF PRIMARY CARE PROVIDER
Description Solution
Currently, the Plan Primary Care Provider (PCP)
setup controls the display of primary care
providers.
This enhancement enables benefits users to
configure, based on life events, whether the
Primary Care Provider page on self-service
enrolment should be displayed. A new field called
Show Primary Care Provider is now available on
the Life Event Reasons form. This new feature
provides you the ability to accept the PCP
information only during the annual or initial
enrolments, and allow the medical carrier to
maintain the PCP information thereafter.
14
RESTRICT DISPLAY OF PRIMARY CARE PROVIDER
New Field
15
ENHANCED INDIVIDUAL CONTRIBUTION DISTRIBUTION
Enhanced Individual Contribution Distribution
Individual Compensation Distribution (ICD) module has been enhanced for Managers and Compensation
Administrators. Line managers can now achieve the following features in the enhanced module:
Can enter multiple input values associated with an element in a compensation plan. User will have the
flexibility to use within ICD, whole or partial list of defined input values associated with an element. It will
be possible to rename input values for display in self-service. Also, user will be able to override sequencing
and updateability of input values within ICD.
Can award multiple compensations of same or different type to an employee within a single transaction on
same or different dates.
Can update and delete active and future compensations (e.g. change the amount dates or delete the
award).
Can indicate a distribution end date for a recurring compensation within the same transaction it is
awarded.
Administrators can do the following actions regarding ICD Plans:
Can configure validation on input values based on Value Sets, Data Types, Minimum, Maximum and
Default, Lookups and Fast Formula.
Can configure element entry flex fields to capture compensation related information for an employee. For
example: Justification for the compensation can now be configured as a flexfield, captured during the
transaction and stored as part of the employee element entries.
Can search employees and update or delete awards
Can view, update and delete element entries that did not originate in ICD
Can configure action items for compensation plans. This will put compensation on hold for a person, until
the action item is provided.
Can default input values as a fixed value or using a fast formula
R12.1 HRMS RUP2
16
17
USE DEFAULT ENROLLMENT TO REINSTATE BACKED OUT INTERVENING EVENTS
Description Solution
In case of intervening LE, the later LE used to
reinstate the older enrollments rather than
the latest one in case of any enrollment
change.
Eg:This is a common situation with Open
enrollment. Enrollments effective Jan 1 are
made in November, then in December another
event like Gain a Dependent occurs. Some
elections are made for the new dependent,
went the Open in reinstated, participant losses
other explicit elections made that were not
impacted by the Gain Dependent.


Benefits Administrators can now use a new
reinstatement code "Reinstate Unless New Explicit
Elections Exist" to reinstate elections made for a
backed out event unless explicit elections have
been made within the plan type for an intervening
event. Example after change:

Open
enrollment
person makes
explicit
enrollment
changes
Gains a
dependent
before Open
enrollments go
into effect

Open backed
out. Explicit
changes made
for new
dependent

When Open reinstates, explicit change made for
the Gain Dependent will default and reinstate
original elections that have not been changed
for the intervening event.
18
USE DEFAULT ENROLLMENT TO REINSTATE BACKED OUT INTERVENING EVENTS
Newly added code
19
USE A NEW SYSTEM PROFILE TO CARRY FORWARD CERTIFICATIONS
Description Solution
Earlier in case of pending action items or EOI the
suspended and interim enrollement was carry
forwarded by using rules which would check of this
scenario and keep them on in case the coverage
restriction is not defined for the LE

A new System Profile, BEN: Carry Forward
Certification has been created to handle this
scenario. Benefit Administrators can carry
forward interim and suspended coverage
created due to coverage restrictions
configured for a life event when subsequent
life events do not have coverage restrictions.
This gives greater flexibility in enforcing
coverage restrictions.
Pre-existing
certification
requirement
needs to be
continued
Certification
required for
coverage over
minimum in
limited situations
Person
experiences
another
enrollment
opportunity
20
USE A NEW SYSTEM PROFILE TO CARRY FORWARD CERTIFICATIONS
New Profile
21
RECALCULATE IMPUTED INCOME
Description Solution
In earlier version, if the an EOI was pending on a
person for a higher coverage subjected to
imputed income then on receiving the
certification, a life event is required to be run to
recalculate the imputed income.
With this enhancement Benefit Administrators get
the flexibility of system recalculating the imputed
income rate as of when coverage subject to
imputed income unsuspends, and changes due to
receipt of certification. The package for calculating
imputed income is updated to calculate
automatically on receiving the certificate based
on:
- Effective date of unsuspended coverage
- Differing coverage start dates within the same
enrollment period


22
SUPPRESS HIPAA IF PARTICIPANT GAINS ELECTABILITY IN ALTERNATE PLAN TYPE
Description Solution
There may be multiple mutually exclusive plan
types within a program that have plans subject to
HIPAA. Person who loses coverage in plans subject
to HIPAA receive the HIPAA communication
although they are in other plans under different
plan types which are also subjected to HIPAA.

This enhancement is to the code of
communication trigger type Participant
Deenrollment - HIPAA which enables Benefits
Administrators to suppress HIPAA literature if a
participant is dropped from coverage in a plan
subject to HIPAA but gains electability to others
plans subject to HIPAA within a different plan type
in the same program. This prevent unnecessary
generation of literature. Eg:


Plan Type B
=
Still has
HIPAA
coverage

Medicare over
65
Regular
Medical for
persons under
65
Plan Type A
R12.1.3
23
24
USER DEFINED CRITERIA FOR DEPENDENT ELIGIBILITY
Description Solution
The current person-related criteria available for
dependent eligibility include Disabled, Marital,
Military and Student statuses. There was not way
to define user defined criteria for dependant
eligibility other than rules. There was additional
setup for this in participant eligibility.
With this enhancement Dependant eligibility form
will have a additional User Dependant Criteria tab
like participant eligibility profile. User defined
criteria profiles allow an expanded choice of
criteria including descriptive flex fields. Using this
benefit administrators will be able to define
dependent eligibility based on an expanded choice
of criteria from PER_ALL_PEOPLE_F such as
Tobacco Use, Benefits Group or descriptive flex
field.

25
USER DEFINED CRITERIA FOR DEPENDENT ELIGIBILITY
New tab form for user defined
eligibility criteria
26
QUERY LIFE EVENT IN ENROLLEMENT WINDOW
Description Solution

The current system does not allow to query Life
Event in Plan enrollement and Program
enrollement window. Due to this if there are
multiple Les then we need to scroll down till the
required LE. This is hectic and time consuming.

With this enhancement, life events can be queried
out easily without scrolling through the whole
other LEs.
27
QUERY LIFE EVENT IN ENROLLEMENT WINDOW
Program enrollement requirement
in query mode
R12.1 HRMS RUP5
28
29
ABILITY TO USE A PERSON SELECTION RULE FOR SYSTEM EXTRACTS
Description Solution
Till now the only parameters for running an extract
was the extract name, effective date, output type
and template. This will run the extract on the
whole population. If the extract was required to be
run only on a set of participant then the extract
criteria had to be modified by adding each
participant name or a person selection set to it.
The enhancement adds person selection rule as an
optional parameter for running a System Extract.
This allows users to collect data for a subset of the
original population on an ad hoc basis without
having to modify the selection criteria in the
extract definition.
30
ABILITY TO USE A PERSON SELECTION RULE FOR SYSTEM EXTRACTS
New parameters would
be added
31
ABILITY TO DISABLE A COMMUNICATION TYPE
Description Solution
With earlier release users were unable to end a
communication type that was no longer being
offered. In case the communication kit is no longer
used a do not send usage rule is attached to the
communication kit. This will keep the
communication kit active in the system but the
rule will prevent it from being send.
With the enhancement users have the ability to
flag a communication type that is no longer in use
to stop it from triggering on a persons record.
32
ABILITY TO DISABLE A COMMUNICATION TYPE
New flag will be added
Currently do not send rule is
attached
33
PROVIDE A NOT ELIGIBLE FLAG FOR COMPENSATION OBJECTS
Description Solution
With the earlier release, if a compensation object
is no longer used a not eligible eligibility
rule(eligibility profile with artificial criteria) is
attached to it which would find all possible
participants ineligible and then continue to
monitor and maintain for the possibility of a
person actually meeting the artificial profile
criteria and hence stops anybody from getting the
compensation object. However the compensation
objects remains in the system without any uses.
Now when a compensation object is no longer
being offered, benefit administrators can flag the
object to be discontinued. When the participation
process is run, it will find all persons ineligible. This
will cause all current participants to be de-enrolled
and prohibit any future ability to enroll. The flag
will be setup at all compensation object level
34
PROVIDE A NOT ELIGIBLE FLAG FOR COMPENSATION OBJECTS
Currently Not elig profile is attached
35
ABILITY TO ATTACH ELIGIBILITY TO LIFE EVENTS AND COMMUNICATION TYPES
Description Solution
With the earlier version Life events are triggered
using any change in person field or with derived
factor. Also communication types are triggered
using their enrollement or any specific rule which
would determine the participants data. There was
no way with which the predefined eligibility
profiles be used to determine these triggers.
In addition to defining a life event based on a
person change, benefit administrators can attach
eligibility profiles so that static data associated
with the person can also be considered when
determining whether a life event has been
detected. Also, eligibility profiles can be associated
with a communication type, adding additional
criteria over the trigger and usage in determine
whether the person should be receiving a defined
communication type. This will reduce the
unnecessary detection of life events and
communication types.

36
ABILITY TO ATTACH ELIGIBILITY TO LIFE EVENTS AND COMMUNICATION TYPES
New will be added
37
DELETE UNRESTRICTED LIFE EVENT ENROLLMENTS
Description Solution
Once an unrestricted life event (Oracle Standard
Benefits) has been detected and started for a
person, there was no process for removing the life
event and any associated benefit enrollement
data. If an unrestricted enrollement was made for
an original hire date, but that date needed to be
moved to a later date, this could not be done as
this would result in benefit information associate
with the person to start prior to their record start
date.
Earlier the only way to delete enrollments related
to Unrestricted event was by running the BEN
Delete script provided by Oracle. This script
deletes all the data in the BEN tables.
Now there is a concurrent process that can be
added to a responsibility which will allow the user
to remove all of the data associated with
Unrestricted enrolments.
38
ENROLLMENT RATE HISTORY IN SELF SERVICE
Description Solution
When a participant is enrolled to a compensation
object over a period, Rates could have changes
over the span of a single coverage period. But in
self service only the current rate is visible and
there is no way to see the different changes in
rate.
With this enhancement, participants will be able
to view all of the rate values associated with an
enrollement result in Self Service. Now
participants can view what the different costs
were over the time period they were enrolled in
the compensation object.
39
REOPEN REINSTATED ENROLLMENT
Description Solution
Before this enhancement, if the reinstated results
were not correct outcome, the life event had to be
manually reopened. There was no way to allow
participants to use self service to make any
adjustments to the backed out enrollement
without benefit professional intervention.
A benefit administrator can now decide whether
reinstated enrolments should be automatically
closed, or whether an enrollement opportunity
should be reopened to allow participants to
confirm or update the reinstated results. The
participants can use self service to make any
adjustments to the backed out enrollement
without benefit professional intervention
40
CLOSE ENROLLMENT WHEN ELECTIONS MADE IN SELF SERVICE
Description Solution
Before this enhancement, when a life event is set
to close when elections are made, it will not close
when the elections are made in Self Service until
the Close Enrollment concurrent process in run.
Now benefit professionals have the ability to allow
participants to close enrolments for which already
elections are made via self service. This would
allow a participant to make elections and proceed
with a subsequent or previously backed out life
event without intervention from the benefit
professional.
mahindrasatyam.com
Safe Harbor
This document contains forward-looking statements within the meaning of section 27A of Securities Act of 1933, as amended, and section 21E of
the Securities Exchange Act of 1934, as amended. The forward-looking statements contained herein are subject to certain risks and uncertainties
that could cause actual results to differ materially from those reflected in the forward-looking statements. Satyam undertakes no duty to update
any forward-looking statements. For a discussion of the risks associated with our business, please see the discussions under the heading Risk
Factors in our report on Form 6-K concerning the quarter ended September 30, 2008, furnished to the Securities and Exchange Commission on
07 November, 2008, and the other reports filed with the Securities and Exchange Commission from time to time. These filings are available at
http://www.sec.gov
THANK YOU
41