oab r12 delta

ORACLE ADVANCED BENEFITS11I-R12 DELTA

1

Jitty_George/Pranab_MajumdarLast Updated On: 16-AUG-2012

ORACLE ADVANCED BENEFITSR12.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 BENEFITSR12.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 PROCESSDescription 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 MODIFICATIONDescription 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 MODIFICATIONProcess to modify Open enrollement window

9

ADDITIONAL INPUT PARAMETERS FOR FAST FORMULASDescription 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 SolutionThere 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 PROVIDERDescription 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 INCOMEDescription 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 hasHIPAA

coverageMedicare over

65

Regular Medical for

person’s under 65

Plan Type A

R12.1.3

23

24

USER DEFINED CRITERIA FOR DEPENDENT ELIGIBILITYDescription 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 ELIGIBILITYNew tab form for user defined eligibility criteria

26

QUERY LIFE EVENT IN ENROLLEMENT WINDOWDescription 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 TYPEDescription 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 person’s 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 participant’s 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