RP e HCM Benefits Ra

HCM Benefits 9.
0 - Understanding Benefits Rates
U N D E R S TAN D I N G B E N E F I TS R ATE S 6/5/2007

HCM Product(s): HCM Release(s): Revision Number: Human Resources / Base Benefits 9.0 1.0
Contains:
Overview of the Benefits Rate Architecture Building a Rate Table Use of the on-line application classes How to extend the delivered set of rate keys
Table of Contents
Table of Contents........................................................................................................................................................3 Chapter 1 - Introduction .............................................................................................................................................4 Structure of this Red Paper Related Materials 4 4
Chapter 2 - Goal of the New Rate Architecture .......................................................................................................5 Design Approach Glossary of Terms 5 5
Chapter 3 - Defining Benefit Rates...........................................................................................................................6 Rate Types Rate Key Sources Building a Rate Table 6 7 8
Chapter 4 - Calculation Rules .................................................................................................................................10 Calculation Rules Setup 10
Chapter 5 - Using the Rate Management Application Classes............................................................................12 Contents of Package BN_RATES Using the BenefitRate Class 12 15
Chapter 6 - Extending the Supported Rate Key Sources.....................................................................................18 Add the Key as System Data Modify Rate Table Component (UI) Objects Modify Benefit Rate Management in COBOL Modify Benefit Rate Management in Application Package Unit Test the New Rate Key 18 18 20 23 25
Appendix A Validation and Feedback ..................................................................................................................27 Customer Validation Field Validation 27 27
Appendix B Revision History................................................................................................................................28 Revision History 28
Copyright 2007 Oracle, Inc. All rights reserved.
6/5/2007
Chapter 1 - Introduction
This Red Paper is a practical guide for technical users, installers, system administrators, and programmers who implement, maintain, or develop applications for PeopleSoft systems. In this Red Paper, we discuss how to establish benefit rates using functionality that has been included in the PeopleSoft Enterprise HCM 9.0 release, how the system processes those rates, and how developers can extend the benefit rate architecture. Much of the information contained in this document originated within PeopleSoft Development and is, therefore, based on "real-life" problems encountered in the field. Although not every conceivable problem that one could encounter is covered in this document, the issues that appear are the problems that prove to be the most common or troublesome.
STRUCTURE OF THIS RED PAPER

This Red Paper provides guidance for the setup of Benefits Rates as utilized by PeopleSoft Base Benefits, Benefits Administration, eBenefits enrollment, and the North American Payroll products of the HCM application. Keep in mind that PeopleSoft updates this document as needed so that it reflects the most current feedback we receive from the field. Therefore, the structure, headings, content, and length of this document is likely to vary with each posted version. To see if the document has been updated since you last downloaded it, compare the date of your version to the date of the version posted on Customer Connection.
RELATED MATERIALS
We assume that our readers are experienced IT professionals with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet architecture, relational database concepts/SQL, and how to use PeopleSoft applications. This document is not intended to replace the documentation delivered with the HCM PeopleBooks. We recommend that before you read this document, you read the PIA related information in the PeopleTools PeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note. Much of the information in this document eventually gets incorporated into subsequent versions of the PeopleBooks. Many of the fundamental concepts related to Base Benefits are discussed in the PeopleSoft Enterprise Human Resources 9.0 PeopleBook: Manage Base Benefits.
6/5/2007
PeopleSoft Enterprise HCM Red Paper
Chapter 2 - Goal of the New Rate Architecture

There are three basic rate application methods: flat amounts, rates per-unit-of-coverage, and percent-ofcompensation base. For HCM 9, we did not change the manner in which rates are applied. The goal of the new rate architecture was to consolidate and provide flexibility in the definition of the criteria used to select an applicable benefit rate. Most notably, this impacts how rates are organized and associated in tables with a common functional usage. As a subtask, we also reorganized the Calculation Rules table such that its attributes control only the determination of rates.All elements related to coverage and premium base were extracted into a new Coverage Formula Table, which is outside the scope of this paper.
DESIGN APPROACH
The new architecture was intended to eliminate the complexity caused by four separate rate table types, defined on different components, stored in different physical records with inconsistent field attributes, and interpreted by different COBOL modules. To that end, all rate types are now defined through a single dynamic component, and stored in a single common data structure. During deduction processing, the rates are retrieved by a single common COBOL module using rules defined on the Calculation Rules table. (With this release there is also a new on-line application class that duplicates the rate management found in the COBOL processes.) The rate definition component needed to be dynamically configurable in order to manage the variety of rate types in current use. For example; flat rates typically have no keys, while age-graded rates have three keys (age, gender, and smoker status). To manage this variety, the Rate Types are now defined as separate entities, with the user deciding the number, order, and types of keys needed. This allows the user to configure the system for new rate usages that match their business processes. PeopleSoft will support an initial limited set of potential rate keys, but the new architecture will allow PeopleSoft developers to extend the framework and add new keys in response to future changes in business practice and client requirements.
GLOSSARY OF TERMS
COMPOSITE RATES Benefit rates expressed generically as employee or employer without reference to a specific tax class. Employee rates are composed of either an after-tax component or a before-tax component; and employer rates are composed of either a taxable component or a non-taxable component. These two generic rate elements (and the resulting benefit cost) will dynamically assume the tax treatment defined within the deduction code associated with the benefit plan using the rate. DETAIL RATES Benefit rates defined with specific after-tax, before-tax, taxable, and non-taxable tax class components. The deduction code associated with the benefit plan using the rate only controls which of the rates defined tax-class components are applicable. RATE METHOD The manner in which a rate value is applied to compute a benefit cost. There are three basic rate methods: flat amounts, rates per-unit-of-coverage, and percent-of-compensation base. RATE TYPE The manner in which a set of rates is organized and associated for common usage, essentially a reflection of the keys used to access and retrieve individual rate values. For examples, service steps, compensation bands, or age-graded. RATESET The rate components (either employee/employer, or the tax-class specific rates) specified on a single row in the Rate Table Data grid. In other words, the rate components associated with a specific set of key values, as would be resolved during cost calculation and retrieved for applying against an employees elected plan to determine its cost.
6/5/2007
Chapter 3 - Defining Benefit Rates

The separation of the definition of rate types from the entry of rate table data itself allows the Rate Table component to dynamically configure itself to present a consistent user interface despite a variety of supported rate structures. The rate type manages how the rate data is collected, interpreted, and applied. It has no rate data associated with it.
RATE TYPES
PeopleSoft will deliver the four rate types supported in previous releases, along with several new rate types that have been actively requested by clients:
Rate Type Age-Graded Flat Length of Service Percent of Base Compensation Bands Covered Person Type Benefit Plan and Coverage Code Keys Gender > Smoker-Status > Age brackets (years) (None) Service brackets (months) (None) Compensation brackets Covered Person Type Benefit Plan > Coverage Code
Compensation Bands
This rate type would most likely be used for health plans, and could allow the employers subsidy to be graduated based on compensation level. The total rates would probably never be tiered based on compensation (this would most likely be deemed discriminatory), but the allocation of benefit cost could be shifted more to the employee at higher compensation levels.
Covered Person Type

This rate type would most likely be used for health plans, and could allow better management of qualified versus non-qualified tax treatment. In prior releases, the rate structures did not support an allocation between before-tax and after-tax. This forced users into using separate plan types for the employee and his qualified family members (associated with a before-tax rate), and a domestic partner and their non-qualified family members (associated with an after-tax rate). These separate plan types were associated through the Benefit Program so they could be consolidated within a single-user presentation in eBenefits self-service benefits enrollment. The new rate architecture, which not only supports individual tax-class rate components, but also supports the definition of rates per covered person type, relieves this complexity. A single rate table can now accurately define the rate makeup for a mixture of covered person types within a single enrollment. During deduction/cost calculations, the modules for health and dependent-life plan types can now analyze the actual list of enrolled covered persons and aggregate the rates for each covered person type involved. . Tips and Tricks: For health plans, the employee is always assumed to be a covered individual, so the rate table must define a row for covered-person type Employee, otherwise the rate resolution process will fail to find a match. If, however, the employee is not a covered individual, then you can simply set all rate components for covered person type Employee to zero ($0).
6/5/2007
Benefit Plan and Coverage Code

In prior releases, each coverage code within each benefit plan within each health plan type was associated with a rate defined in an individual, flat-rate table. Unless the user created a standardized naming scheme, there was no convenient way to group these rates for maintenance or reporting, so managing a provider-negotiated rate schedule was awkward. This new rate type will facilitate the organization of rates from a provider into a single rate table. Note that Coverage Code based rates can define all tax classes, just as Covered Person Type keyed rates can. When using Coverage Codes, however, the system is more concerned with the mix of individuals, rather than the number of individuals. The system does not, in fact, look at the list of covered persons to resolve Coverage Code based rates.
RATE KEY SOURCES

In addition to these delivered rate types, clients will be able to create new rate types using combinations of the following supported key sources:
Rate Key Source Age (Years) Attributes Number from 0 to 999 (As computed using the Use-Age-As-Of and Source-for-Demographics rules on the Calculation Rules table) Character with standard Translate values. (As determined using the Source-forDemographics rule on the Calculation Rules table) Character with standard Translate values (As determined using the Source-forDemographics rule on the Calculation Rules table). Character with standard Translate values (As determined using the Source-forDemographics rule on the Calculation Rules table). Number from 0 to 999 (As computed using the Use-Service-As-Of rule on the Calculation Rules table) Number to 99,999,999,999.999 (As computed using the Benefits-BaseSource, Use-Benefits-Base-As-Of and Multiple-Jobs rules on the Calculation Rules table) Character with prompt against Benefit Plan Table (for Plan Types 1X, 2X, 3X and AX only). Basis Field PERSON.BIRTHDATE for the employee; Field DEP_BEN.BIRTHDATE for a covered dependent. Field PERS_DATA_EFFDT.SEX for the employee; Field DEP_BEN_EFF.SEX for a covered dependent. Status from PERS_SMOKER record for the employee; Field DEP_BEN_EFF.SMOKER for a covered dependent. Always Employee for the employee; For a covered dependent, use DEP_BEN_EFF.RELATIONSHIP field and cross-reference to the Dependent Relationships Table. Field PER_ORG_ASGN.SERVICE_DT for the employees (benefits) primary Job. Field JOB.ANNUAL_RT from the employees Job record(s), or Field ANNL_BENEF_BASE_RT from the Annual Benefits Base Rate record(s). From the employees applicable Base Benefits election, or the Option being processed by Benefits Administration. From the employees applicable Base Benefits election, or the Option being processed by Benefits Administration.
Gender
Smoker-Status
Covered Person Type
Service (Months)
Compensation
Benefit Plan
Coverage Code
Character with prompt against Coverage Code Table.
6/5/2007
Note. The rate architecture supports the addition of new rate key sources, but not as a client configuration. The architecture is designed to be extendable by PeopleSoft Development in a minimally disruptive process (without data structure impact), such that PeopleSoft can be more responsive to changing user needs. See chapter below.
BUILDING A RATE TABLE

The actual benefit rate data is entered into the Benefit Rate Table component. A rate table is associated with a rate type, which gives the table its structure and functionality.
Entering Rate Data - Keys

Most notably, the rate type defines how many and what type of keys are used to collect and organize the rate data. A table built on a Flat-Rate rate type has no keys and defines a single rateset
The Length-of-Service rate type uses a single numeric bracket to define ratesets according to tiers of service
The Benefit-Plan/Coverage-Code rate type has two keys, both of which are from prompt tables, to define ratesets by combinations of plan and coverage
The Age-Graded rate type has three keys (two based on specific translate values and one numeric bracket) to define ratesets based on combinations of gender and smoker status broken down by age tiers
6/5/2007
Tips and Tricks: The rate type may define a numeric bracket using one of several comparison methods: >, >=, < or <=. It is important to keep the comparison method in mind when entering rate data. An entry may or may not include the breakpoint. For example, if the numeric bracket is Age (>) and an age tier of 25 is entered, then an employee who is 25 actually matches the previous rate row, because the current rate row is only for employees greater than 25. If the numeric bracket were defined as Age (>=) then the same employee would match the current rate row, because it includes the age 25 tier breakpoint. Further, make sure that the tiers entered include the expected minimum or maximum range values as appropriate. In the example screenshot above, if the age brackets started at 1 rather than 0, then a newborn child might fail the rate resolution processes.
Entering Rate Data - Style

The rate table allows rate data to be entered in one of two styles: Composite rates Detail rates
Each rateset (row of rate data) can be entered in either style, as best fits its intended use. (While the style can vary with each row, using mixed styles would be unusual.) Composite rate entry has the most flexibility, and maintains the entry style used in previous releases. Composite rates, however, have the restriction that the employee component must be either after-tax or before-tax, and the employer component must be either taxable or nontaxable. The deduction code associated with a composite rate should never define multiple employee or employer tax classes. The benefits deduction/cost calculation routines cannot allocate costs between competing deduction classes, and they would most likely end up assigning the full rate to both tax classes, effectively doubling the deduction. When greater control is needed over the tax-class allocation of a rate, then the Detail rate entry style should be used. This allows the user to specify the rate component for each tax class. (In current practice, this is most often required for health insurance rates, where the issues of qualified versus non-qualified individuals, or coverage of overage dependents, require a more dynamic management of tax impacts).
Tips and Tricks: Do not use the Detail style of rate entry for Life plans subject to imputed income. In general, the benefits deduction/cost routines have special logic for determining imputed income, as triggered by tax-effect attributes on the deduction code. Specifying a distinct Taxable rate component would interfere with the systems built-in ability to manage imputed income.
Entering Rate Data Currency Code

The PeopleSoft Benefits products and PeopleSoft Payroll for North America do not perform currency conversion. Both applications assume that within a process run, all currencies are consistent with the target currency. For Benefits, the currency code on the Benefit Program is strictly informational. The user must take care when building a program, that all rates attached to the option costs are using the same currency. Under the new rate architecture, all rate tables also have an optional, informational currency code. Again, no currency conversion is implied or performed. When building a Benefit Program, however, the system will now assist the user by using the Programs currency as a filter and only including matching rate tables in the prompting on the Cost Definition page (any rate table with a blank currency code is also included). This should help reduce any cross-currency mistakes. The currency codes are not otherwise validated when the rates are ultimately used in benefits or payroll processes.
6/5/2007
Chapter 4 - Calculation Rules

In previous releases, the Calculation Rules table held a combination of rate rules and coverage rules. The separation of these rules, and their application during processing, was not always clear. In HCM 9.0, however, the definition of coverage and the specification of coverage calculation rules were significantly restructured as part of the Life Insurance Enhancements - Coverage Formula project. Because of this, as part of the new rate architecture, the Calculation Rules table was restructured to be focused only on benefit rate application.
CALCULATION RULES SETUP
This section of the rules setup defines how biographical information should be managed, if such information serves as the source for a rate key. The Age and Service rules carry over from previous releases. The Source for Demographics field values have been expanded to include the Employee, any Covered Dependent, or specifically the employees Spouse/Partner. The rate resolution routines will attempt to honor this rule whenever applicable. A new Age option is available: Age as of the employees initial coverage under a plan. The system resolves this value by analyzing the employees enrollment history for the plan type. Starting with the current (or target) benefit plan, the system looks back in history and finds the earliest Coverage Begin Date for which the employee has experienced uninterrupted coverage under the benefit plan. (A waive, a termination, or a change in benefit plan would be considered a break in coverage and would cause the analysis to stop.) A business use for a rate using this kind of age criteria would be long-term care, where the premium is typically fixed based on the employees age when they first elect coverage (since the providers risk is measured by longevity tables, and the potential coverage is largely open-ended).
This section of the rules setup is cloned from the similar rules that previously controlled the Coverage and Premium bases. The functionality is the same, but the resulting compensation is used only in the context of resolving or applying a benefit rate. A compensation base would be needed when a rate is defined as a Percent of Base. In general, if the benefit plan involved carries its own definition of a coverage amount, then the rate will be applied against that defined amount.
10
6/5/2007
If however, that coverage amount is zero, or if the plan involved does not support an independent coverage amount, then the system will use the Calculation Rules Benefit Base rules to determine a compensation base. A compensation base may also be required if the rate table involved uses compensation directly as a rate key (for example, Compensation Bands). In this case, the system must determine a base to use for accessing the rate data, matching to the compensation brackets, and selecting the target rateset.
11
6/5/2007
Chapter 5 - Using the Rate Management Application Classes

A family of classes was developed to allow the same kind of rate management to be performed online as is currently performed in batch (COBOL) during cost and deduction calculations. Rate management is all activities related to the selection of a single applicable benefit rate for use in a cost calculation. This includes retrieving and caching: The rate type and rate table definitions for performance. The calculation rules associated with the rate table in the benefit program. Job and compensation information for an employee to allow for the determination of the benefits base (should it be required). Biographical information for both the employee and his dependents (should it be required for key resolution).
These classes are part of the BN_RATES application package. Currently, the main consumers of these classes are the Benefits Premium Report (Application Engine process BEN110) and eBenefits Enrollment (Life plan elections).
CONTENTS OF PACKAGE BN_RATES

While the BN_RATES application package contains a variety of rate-related sub-packages, the only direct consumer class is BenefitRate. All other classes simply support BenefitRate, and are not intended to be used independently. Package: RateAccessMgmt Class: BenefitRate method The main consumer class, this class exposes two public methods to the user: getRateSet() determines the single applicable benefit rateset from the supplied input information, and getRateRules() which retrieves Rate Table and Calculation Rules Table definitions for use by an application. &bResult = getRateSet(&sRateTableID, &sCalcRuleID, &dAsOfDate, &oRateKeys); This method determines the single applicable benefit rateset from the supplied input information. The methods Rate Table, Calculation Rule, and As-Of Date arguments indicate the rate to be resolved, and the RateKeys argument contains the variable employee information towards which the rate is targeted. If successful (methods return result is True), then the BenefitRate objects properties will hold the retrieved rateset information. method &bResult = getRateRules(&sRateTableID, &sCalcRuleID, &dAsOfDate); This method can be used to retrieve the indicated Rate Table and Calculation Rule management objects from cache. These are the managers that would be used to resolve the rate. If successful (methods return result is True), then the BenefitRate objects properties will hold the retrieved manager objects. The application can then access the properties of these managers for its own use.
12
6/5/2007
properties
string RateTblID, CalcRuleID date AsOfDate These represent the keys last used for rate retrieval, as passed as arguments to either getRateSet() or getRateRules().
properties
boolean RateFound number TotalRate boolean CompositeRateStyle number EmployeeRate, EmployerRate number BeforeTaxRate, AfterTaxRate, NonTaxableRate, TaxableRate These represent the results of the last call to getRateSet(). RateFound indicates the success of that rate retrieval (if RateFound is False, then HasErrors will necessarily be True). The TotalRate is the sum of all rate components, and represents the rate charged by, and due to, the provider. CompositRateStyle indicates which style of rate entry was found if True, then the user should use the EmployeeRate/EmployerRate pair; if False, then the tax-class specific properties should be used.
properties
boolean HasErrors array of BN_RATES:Common:AppMsg AppMsgs These properties support error management. HasErrors indicates whether any errors were encountered by a method call, and if True then the AppMsgs array will hold the specific error information. See the PeopleTools Exception class for more information.
properties
BN_RATES:CalcRulesMgmt:CalcRuleDefn CalcRule BN_RATES:RateDefnMgmt:BenefitRateDefn RateTbl BN_RATES:BenefitBaseMgmt:BenefitBase BenBaseMgr BN_RATES:DependentListMgmt:Dependents DpndMgr These are the underlying manager classes that support rate resolution. These are not intended for direct interaction, but they are nevertheless exposed because the application may have need to access properties from these objects. Each manager will have available properties established as a result of the last getRateSet() call.
Package: RateAccessMgmt Class: UserRateInput
This is also intended for use by the consumer, and is simply a values class that serves as an information-passing mechanism. The class is used to pass information about the employee, his election, his biographical and job data, and his covered dependents, to the BenefitRate class as keys to the retrieval of a rateset. (In some cases, if the information is not known to the application, the BenefitRate class can acquire it independently. Passing all known background information to BenefitRate, however, improves performance by avoiding unnecessary database access.)
13
6/5/2007
method
clearEmployee() clearDependent() clearEnrollment() clearAll() These methods simply clear various related class properties in preparation for use in a getRateSet() method call. Method clearDependent() should be called whenever a different dependent will be processed, or to switch between rates based on a covered person to a rate based on the employee (if the BenefitRate object sees a non-blank DepID property, then covered person processing may be triggered inappropriately).
properties
string EmplID integer EmplRcd These properties represent the minimum keys necessary to resolve a benefit rate. Using these keys (and the As-Of Date supplied as part of the getRateSet() call), the rate management object can obtain all necessary employee-related information from the database.
properties
integer BenefitRcdNbr date Birthdate string Sex string Smoker integer Age string CoveredPersonType date ServiceDate date TerminationDate integer LengthOfService number BenefitBase string HCE_Indicator These properties represent the biographical and employment background information required to resolve the full range of supported rate key sources for the employee. These properties are read/write. If the user supplies this information it will be used when needed to resolve the rate keys; if this information is needed but not supplied, the class will perform database accesses as required and load the results back into these properties.
properties
string DepID string DpndSex string DpndSmoker date DpndBirthdate integer DpndAge string DpndCoveredPersonType These properties represent the biographical background information required to resolve the full range of supported rate key sources for a covered dependent. These properties are read/write if the user supplies this information it will be used when needed to resolve the rate keys; if this information is needed but not supplied, the class will perform database accesses as required and load the results back into these properties. Note, however, that when a covered dependent is the basis for a rate key, then the DepID property becomes a minimum required key that must be user-supplied, since all other information can be conditionally retrieved from it.
14
6/5/2007
properties
string PlanType integer CobraEventID string BenefitPlan string CovrgCd These properties represent the enrollment background information required to resolve the full range of supported rate key sources for the employee. These properties are read/write if the user supplies this information it will be used when needed to resolve the rate keys; if this information is needed but not supplied, the class will perform database accesses as required and load the results back into these properties. Note, however, that when an enrollment is the basis for a rate key, then the PlanType property (and possibly CobraEventID for 1X Plans) becomes a minimum required key that must be user-supplied (since all other information can be conditionally retrieved from it)
SubPackage: BenefitBaseMgmt
The classes in this sub-package duplicate much of the logic found in the PSPDCOMP.CBL COBOL module. The classes manage the determination of an appropriate benefits compensation base, when such base is needed for either rate resolution (For examples, Compensation Bands rate type, or Percent-of-Base rate method) or coverage amounts. The classes cache an employees job and compensation history, and then use the applicable calculation rules to select or aggregate relevant compensation. The classes in this sub-package retrieve and cache entries from the Calculation Rules table as they are needed to perform rate resolution. These are mainly values classes holding the rule definition of interest. The classes in this sub-package retrieve and cache a list of an employees dependents at a point in time. These are mainly values classes holding biographical information about a dependent of interest, but also has the ability to find a particular dependent by ID, or to find the employees current spouse/partner. The classes in this sub-package retrieve and cache entries from the Rate definition tables (Rate Keys, Rate Types and Rate Tables) as they are needed to perform rate resolution. These are mainly values classes holding the rate definition of interest. This class gets internally instantiated as a global session object that holds the singleton instances of each of the cache managers (Benefit Base, Calculation Rules, Rates, and Dependents). This allows the cache lists to be persistent across applications and components for maximum performance gain. The classes in this sub-package represent common support functions shared by other classes. Currently, the main feature is the application error management classes. Class AppMsgCat is a values class with symbolic constants for the various Message Catalog entries used by the BN_RATES package. Class AppMsg extends the Exception class and manages the reporting of errors, including the resolution of substitution parameters and the retrieval of a messages long descriptive text.
SubPackage: CalcRulesMgmt SubPackage: DependentListMgmt
SubPackage: RateDefnMgmt SubPackage: GlobalBenefitRateMgr
SubPackage: Common
USING THE BENEFITRATE CLASS

Despite the number of supporting classes in the BN_RATES package, there are really only two consumer classes with which an application interacts: UserRateInput (as an information-passing device), and BenefitRate. The following example shows the retrieval of rates from several rate table types there is a single interface to retrieve rates regardless of rate type, but the input data can vary.
15
6/5/2007
Import the appropriate application packages and class definitions.

import BN_RATES:RateAccessMgmt:*;
Declare local variables and instantiate the two rate management objects.
Local Local Local Local Local Local Local BN_RATES:RateAccessMgmt:BenefitRate &oRateMgr; BN_RATES:RateAccessMgmt:UserRateInput &oRateKeys; number &nOptionRate, &nProviderPremium; string &sCalcRuleID, &sRateTblID; date &dAsOfDate; integer &I; boolean &bResult;
&oRateKeys = create BN_RATES:RateAccessMgmt:UserRateInput(); &oRateMgr = create BN_RATES:RateAccessMgmt:BenefitRate();
Establish the input criteria needed to retrieve a rate. The application is responsible for determining the correct Rate Table and Calculation Rules IDs to be used, the overall as-of date, and the minimum employee-specific rate keys. Note that if the application already knows some of the potential rate key values (for this example, gender, smoker status, or birth date), they can be supplied through the RateKeys object. Doing so would avoid the overhead of the RateMgr having to independently acquire this information through database access.
Rem: Prepare to retrieve rateset for an Age-Graded Rate Table; &sRateTblID = "KA01"; &sCalcRuleID = "KAG1"; &dAsOfDate = Date(19980801); &oRateKeys.EmplID = "KU0010"; &oRateKeys.EmplRcd = 0; Rem If the application has this information, pass it for increased performance...; Rem &oRateKeys.Sex = &oRecPersDataEff.Sex.Value; Rem &oRateKeys.Smoker = "N"; Rem &oRateKeys.Birthdate = &oRecPerson.Birthdate.Value;
Invoke the getRateSet() method. The system will retrieve and cache the Rate Table and Calculation Rules definitions effective on the as-of date; determine if it has sufficient key information (and if not, acquire the biographical or job/employment information needed); resolve/compute the required keys; and retrieve the target Rate Data from the table.
&bResult = &oRateMgr.getRateSet(&sRateTblID, &sCalcRuleID, &dAsOfDate, &oRateKeys);
If any errors were encountered, the application can access them and display them to the user.
If (&oRateMgr.HasErrors) Then For &I = 1 To &oRateMgr.AppMsgs.Len WinMessage(&oRateMgr.AppMsgs [&I].ToString()); End-For; Else
If successful, the components of the rate (the rateset) are available as read-only class properties.
Rem: Use the retrieved rate information...; If (&oRateMgr.CompositeRateStyle) Then &nOptionRate = &oRateMgr.EmployeeRate; Else &nOptionRate = &oRateMgr.BeforeTaxRate + &oRateMgr.AfterTaxRate; End-If; &nProviderPremium = &oRateMgr.TotalRate;
Furthermore, any background information acquired by the RateMgr in order to select and return the rateset are loaded back into the RateKeys object where they are available to the application as properties.
16
6/5/2007
Rem: Use the retrieved employee biographical information...; WinMessage("EE was born " | &oRateKeys.Birthdate | " and age is " | &oRateKeys.Age); WinMessage("EE's gender is " | &oRateKeys.Sex); End-If;
Establish the input criteria needed to retrieve a second rate. Note that the RateKeys object still holds the employee key (and any biographical and employment background information) from the previous use. The RateKey method clearAll() would be used to clear all existing information if a new employee was being processed, but calling clearAll() or clearEmployee() unnecessarily would force the Rate Manage to simply reacquire the same information over and over. In this example, we must supply the ID of a specific target Dependent, whose biographical information will control the rate selected
Rem: Prepare to retrieve rateset by Covered Person Type for a specified Dependent...; Rem &oRateKeys.clearAll(); &sRateTblID = "BUCP"; &sCalcRuleID = "KAGD"; &dAsOfDate = Date(20050101); Rem &oRateKeys.EmplID and .EmplRcd already set from previous use; &oRateKeys.clearDependent(); &oRateKeys.DepID = "01";
Invoke the getRateSet() method. Rather than testing the RateMgr objects HasError property, we can simply respond to the Boolean result returned by the getRateSet() method
if (&oRateMgr.getRateSet(&sRateTblID, &sCalcRuleID, &dAsOfDate, &oRateKeys)) Then Rem: Use the retrieved rate information...; Rem: Use the retrieved dependent biographical information...; WinMessage(&oRateKeys.DepID | " is a " | &oRateKeys.DpndCoveredPersonType); Else For &I = 1 To &oRateMgr.AppMsgs.Len WinMessage(&oRateMgr.AppMsgs [&I].ToString()); End-For; End-If;
17
6/5/2007
Chapter 6 - Extending the Supported Rate Key Sources

The rate architecture allows the addition of new rate key sources, but not as a client configuration. The architecture is designed to be extendable by PeopleSoft Development in a minimally disruptive process (without data structure impact), such that PeopleSoft can be more responsive to changing user needs. This chapter outlines the steps that a developer would take to implement support for additional rate key sources. The discussions below will be illustrated by a fictional implementation of a new rate key for State. (This does not imply this has any real functional value to actual business practices!). This example information will be shown in blue, italics type.
ADD THE KEY AS SYSTEM DATA

The supported rate keys are defined in table BN_RATE_KEYS as System Data. This table does not have a component available to manage it, since its data is intended to be maintained internally by Development. Therefore, the new key must be added manually through SQL: Note. At this time, the architecture can only support character and numeric keys it cannot support date, datetime, or long. Furthermore, numeric keys can have a maximum precision of six decimal places.
BN_RATE_KEYS FieldName FIELDNAME
BN_FIELDNAME_ALIAS
LABEL_ID BN_USES_COMPENSATN
BN_USES_DEMOGRPHCS
DATA_TYPE_CD
The name of the existing record field that will be the basis for the new key. Example: STATE An alternate fieldname to be used in the Rate Table component. This name does not represent an actual field, but is the root for a series of derived work fields of the same name with 01, 02 and 03 appended. As such, this name cannot be larger than 16 characters. By convention, the alias is usually in the form BN_fieldname_KEY. Example: BN_STATE_KEY An optional alternate field label. If blank, the system will use the fields default label on the grid on the Rate Table page. If the new key requires the system to determine an employees Benefits Base in order to resolve its value, then set this indicator to Y, otherwise set it to N. This has both informational and performance impacts. If the new key requires the system to retrieve a covered persons personal biographical data in order to resolve its value, then set this indicator to Y, otherwise set it to N. This has both informational and performance impacts. Set to Y to indicate that PeopleSoft controls this data.
MODIFY RATE TABLE COMPONENT (UI) OBJECTS

The Rate Table component uses a grid based on a set of derived work fields to achieve its dynamic configurability in response to a rate type definition. This grid, and the underlying DERIVED_BN_RATE record, must be modified to include the new rate key being supported.
18
6/5/2007
Create Work Fields

You must create a series of three support work fields by cloning the basis field (see previous section) into three copies using the Fieldname Alias as the root and appending 01, 02, and 03 to the name. We retain the attributes of the basis field and its Translate entries (if any), however, the Field Description is replaced as indicated with a fixed sentence, the Object Owner ID is set to Benefits, and we replace all existing field labels with a single Default Label Name to match the new key field usage.
Clone Base Field Example: STATE Into Three Copies Example: BN_STATE_KEY01 BN_STATE_KEY02 BN_STATE_KEY03 Value (Retain attributes of Base Field) Example: Work State / State This field is used in the management of benefit rate tables, and participates in the dynamic grid configuration of the Rate Table keys based on the rate type definition. (Retain translate items from of Base Field)
Field Attribute Field Type and Size Default Label Text Description
Translate Values
Modify Derived Work Record

The three new work fields must be added into the DERIVED_BN_RATE record, which is used to manage the dynamic grid of rate data. Distribute the new fields onto the end of the respective existing 01, 02, and 03 key field groupings. Then, define an Edit criteria (Xlat or Prompt Table) as applicable to match the typical usage of the basis field. Note. In our example, STATE is typically prompted against STATE_TBL, but since its higher-level key COUNTRY is not present, we would not be able to include this prompt in the Rate Table page.
Modify Rate Data Page

The three new work fields must be added into the Rate Data grid of the Rate Table page. Distribute the new fields onto the end of the respective existing 01, 02, and 03 key field groupings, as either an Edit Box or a DropDown List as appropriate to its edit method. Use the RFT-Long field description for the label, set the Freeze Grid Column attribute, and give each field a PageField Name equal to its FieldName. Note. The placement of the fields in the grid is critical to the dynamic management of the page. Based on the r3ate type definition, one key from each numeric grouping may be exposed to the user and the rest will be hidden.
Add Component PeopleCode Events

The three new work fields will be dynamically managed through the BenefitRateUIMgr application class. This class implements all of the PeopleCode logic used by the component. The component simply makes calls to various event manager methods in the application class. For each new key field, add the following generic componentlevel PeopleCode:
19
6/5/2007
Component PeopleCode Event DERIVED_BN_RATE [BN_STATE_KEY01] [BN_STATE_KEY02] [BN_STATE_KEY03] FIeldChange
Business Logic import BN_RATES:RateUIMgmt:BenefitRateUIMgr; Component BN_RATES:RateUIMgmt:BenefitRateUIMgr &c_oRateMgr; &c_oRateMgr.onFieldChangeRateKey(GetField());
MODIFY BENEFIT RATE MANAGEMENT IN COBOL

Benefit Rate management is compartmentalized in a single COBOL module PSPBENRT.CBL and its companion copybook and stored SQL script. In managing a rate key, the system must be able to: 1. Derive the value of the key for the current employee (key resolution). 2. Convert the key value into a common working format (key conversion). 3. Perform a matching of the resolved rate key value against the Rate Data to select a single applicable rate (key matching). The first two of these activities (resolution and conversion) are highly specific to each rate key, and the paragraphs that perform them must be extended to support each new key. Key matching, however, operates on the fully resolved and converted key data, and is, therefore, independent of the original key source.
Rate Key Resolution

We must declare the new rate key to the program by adding a symbolic constant (88-level) to the Rate Key cache. Continuing with our State example:
PSPBENRT.CBL: WORKING-STORAGE 01 W-RATE-CACHE. 02 RATE-TBL-CACHE 03 RATE-KEY-CACHE 04 FIELDNAME 88 RTKEY-AGE VALUE AGE. 88 RTKEY-STATE VALE 'STATE'.
Currently, all supported rate keys are based on fields already available through the common storage areas within the deduction calculation modules. For example the CHECK structure or the DARRY array hold gender, birth date, smoker status, service-date, covered person type, benefits plan and coverage code. If the new rate key being implemented is already retrieved and managed through these commonly passed structures, no additional storage is required. For some keys, like Age and Length-of-Service, even though their source fields are available, they are actually computed values that must be temporarily stored. So depending on the nature and sourcing of the new rate key being implemented, you may need to create a new working storage member to manage it.
20
6/5/2007
PSPBENRT.CBL: WORKING-STORAGE * * * 01 W-SOURCE. Break keys... ... Personal Data attributes... 02 AGE-YEARS PIC 999 Job and Employment Data attributes... 02 SERVICE-MONTHS PIC 999 02 CALCULATED-BASE PIC 9(8)V9(2) 02 WORK-STATE PIC X(6).
COMP. COMP. COMP-3.
If a new working storage member is created for the key, it must also be added to paragraph A1000-INIT-RATEMGMT, which initializes these members upon an employee break. Paragraph HA000-RESOLVE-RATE-KEYS is the central manager for key resolution. It consists mainly of an Evaluate clause that uses the rate type definition (which defines the rate keys being used) to redirect the logic flow to a key-specific resolution paragraph. This Evaluate must be extended by appending another WHEN condition with the 88-level constant created above for the new rate key being implemented. When the condition is met, we simply perform an associated new rate key resolution paragraph (in the J series). The J-series rate key resolution paragraphs all follow a common organization, with variations depending on whether the key is a computed value, whether is can be sourced from both the employee or a covered person, and whether the module itself must perform the database retrieval. Here is some pseudo-code that outlines the existing resolution schemes:
21
6/5/2007
PSPBENRT.CBL: J-Series Paragraphs Initially default the KEY-VALUE-KNOWN flag to NO.
If (The key is based on the Employee, not a Covered Dependent) Then Check commonly shared data structures or local working storage, as applicable. If (The key has a value) Then Set the KEY-VALUE-KNOWN flag to YES. End-If Else (The key is based on a Covered Dependent) Check the passed BNDEP Dependent Information structure. If (The key has a value) Then Set the KEY-VALUE-KNOWN flag to YES. End-If End-If If (The KEY-VALUE-KNOWN flag is still NO) Then If (The key must be computed using known values) Then Attempt to compute the key using applicable source information (Commonly shared data, local working storage, or BNDEP Dependent Info) If (The key was successfully computed) Then Store computed value back into appropriate common data structure. Set the KEY-VALUE-KNOWN flag to YES. Else Optionally throw error to report missing or bad source data. End-If Else If (The key must be retrieved from the database) Then Attempt to retrieve key from database using applicable source information. (Commonly shared data, local working storage, or BNDEP Dependent Info) If (The key was successfully retrieved) Then Store retrieved value back into appropriate common data structure. Set the KEY-VALUE-KNOWN flag to YES. Else Optionally throw error to report missing or bad source data. End-If End-If End-If If (The KEY-VALUE-KNOWN flag is still NO) Then Throw a general key resolution failure error. End-If
Note. In our example, STATE is not a field that is currently managed during the deduction calculation process, and it is not available through the common data structures. As such, you would have to create a holding place for it in local working storage (01 W-SOURCE), and retrieve it directly from the database through a new GET-WORKLOCATION paragraph, supported by the appropriate 01 SQL buffer structures and an appropriate stored SQL statement in the DMS file. This would probably require access to the employees LOCATION on Job, and then to the work locations STATE via the LOCATION_TBL. This determination is based on the employees job information and does not involve covered dependents in any way, so those contingencies in the above pseudo-code can be ignored.
Rate Key Conversion

Because of the flexibility required by the configurable rate types, we must be able to support both character-based and numeric keys. This is problematic for the rate data itself, however, which needs a consistent set of keys for database storage. To address this, we have keyed the rate data using three generic CHAR(20) record keys. This means that numeric rate keys (such as Age, Service-months, and Compensation amount) must be converted into a standardized character format when stored to the database. The inverse is also true when the COBOL modules need to compare the numeric target rate keys, they must first be converted into the standardized character format so they can be accurately compared to the stored rate data keys. 22
6/5/2007
Paragraph NA000-CONVERT-RATE-KEYS is the central manager for key conversion. It consists mainly of an Evaluate clause, which uses the Rate Type definition (which defines the rate keys being used) to determine where to obtain the resolved key, and whether that key needs conversion. This Evaluate must be extended by appending another WHEN condition with the 88-level constant created above for the new rate key being implemented. When the condition is met, we perform a simple move of the resolved key and a subsequent conversion if it is numeric. Here is some pseudo-code that outlines the existing conversion schemes:
PSPBENRT.CBL: NA000-CONVERT-RATE-KEYS When the key is character-based ... Determine where the resolved key resides. Move it into the RESOLVED-RATE-KEY holding area. When the key is numeric ... Determine where the resolved key resides. Move it into the W-CONVERT holding area. Perform NA100-CONVERT-RATE-KEY Move converted value from W-CONVERT into the RESOLVED-RATE-KEY holding area.
MODIFY BENEFIT RATE MANAGEMENT IN APPLICATION PACKAGE

Benefit Rate management processes are also available on-line through the BenefitRate application class in the RateAccessMgmt sub-package of BN_RATES. This class essentially duplicates the COBOL rate management. Therefore, to implement support for a new rate key, very similar changes must be made to this application package.
Rate Key Passing

As in the COBOL deduction calculation process, certain rate key values may already be known to the calling application, and can optionally be passed into the BenefitRate management class to avoid the overhead of having the class reacquire the information. Such information is passed using the UserRateInput values class. This class should be modified to include the new rate key as a property. The BenefitRate manager will check this property, and if non-blank will use that value to access the desired rates, if blank, the BenefitRate manager will know it must independently acquire the information.
BN_RATES:RateAccessMgmt: UserRateInput property string WorkState;
The new property would also be added to the class clearEmployee() method (and possibly clearDependent() ), where it would be initialized appropriate to its data type.
Rate Key Class

Each rate key is managed by a specific subclass, which is an extension of class RateKeyBase. Each subclass is responsible for implementing interface method resolveKey(), whose goal is to resolve the current key value (either by getting it from the passed UserRateInput object, or through calculation, or directly from the database) and converting it into a standardized format so it can be used to access the desired target Rate Data. Create a new RateKey subclass, either empty or by cloning an existing RateKey subclass as a starting point.
BN_RATES:RateAccessMgmt Class RateKeyState extends BN_RATES:RateAccessMgmt:RateKeyBase;
23
6/5/2007
Implement (or modify) the resolveKey() method as required to copy, calculate, or retrieve the key value. (The work done above for the equivalent COBOL process should already have given you the methodology youll need). Here is some pseudo-code that outlines the existing resolution schemes:
BN_RATES:RateAccessMgmt:RateKeyXXXX.resolveKey() Initially default the KeyResolved flag to NO. Check the passed UserRateInput class or current class members, as applicable. If (The key has a value) Then Set the KeyResolved flag to YES. End-If If (The KeyResolved flag is still NO) Then If (The key must be computed using known values) Then Attempt to compute the key using applicable source information (UserRateInput class or current class members) If (The key was successfully computed) Then Store computed value back into appropriate common class structures. Set the KeyResolved flag to YES. Else Optionally throw error to report missing or bad source data. End-If Else If (The key must be retrieved from the database) Then Attempt to retrieve key from database using applicable source information. (UserRateInput class or current class members) If (The key was successfully retrieved) Then Store retrieved value back into appropriate common class structures. Set the KeyResolved flag to YES. Else Optionally throw error to report missing or bad source data. End-If End-If End-If If (The KeyResolved flag is still NO) Then Throw a general key resolution failure error. Else Convert the key value, if necessary. End-If
Note that the base class RateKeyBase has several methods already in place to retrieve information for some common sources, such as Personal Data or Job and Organizational Assignments. If the new rate key resides on these records then the existing retrieval methods could be enhanced to include it. Otherwise, you will want to create a special-purpose retrieval local to the specific rate key class that you are creating. (If such retrieval requires hardcoded SQL, then use a SQL Object to manage it to retain the current style of the application package. Note. In our example, STATE is not a field that is currently managed by the UserRateInput class. As such, you would have to add it as a new public class property. Within the RateKeyState subclass, you would have to retrieve it directly from the database if it was not passed. In a manner similar to retrieveEmployeeBiographics() or retrieveEmployeeJobHistory(), you would create a new private method retrieveWorkState() and new SQL object BN_RATE_WORKSTATE to facilitate this. The actual SQL would be very similar to that created for the PSPBENRT COBOL module.
Rate Key Factory

To shield the BenefitRate consumer class from the complexities of the various supported rate keys, the RateKeyFactory class is used whenever we need an instance of a particular RateKey manager. The factory is the only class that knows about the individual rate keys it determines which type of RateKey subclass to instantiate,
24
6/5/2007
and returns it to the BenefitRate manager as an anonymous RateKeyBase object. This means that when we add support for a new rate key type, we must extend the Evaluate statement used in the factory to include an additional WHEN condition for the new rate key, using the keys FieldName.
UNIT TEST THE NEW RATE KEY

There are several key functional areas that must be tested to confirm that the new rate key has been fully and properly implemented.
Benefit Rate Definition

These test scenarios exercise the basic rate definition functionality, and confirm that the new rate key can be used when building a rate table. Does the new key appear in the Field Name dropdown list in the Benefit Rate Type component? Are its attributes reported correctly? Can you create a new rate type using the new key? o Setup HRMS > Product Related > Base Benefits > Rates and Rules > Rate Type Table Can you create a new rate table using a rate type incorporating the new key? Does the Rate Data grid configuration reflect the label, data type, and prompting of the new key? Can you enter data (and trigger expected validations) into the new key field, and save the rate table? When the Rate table is recalled does it reflect the correct data entry? o Setup HRMS > Product Related > Base Benefits > Rates and Rules > Benefit Rate Table Does the Benefit Rate Table report (BEN741) display a rate table appropriately using the new key (label and data type)? o Setup HRMS > Product Related > Base Benefits > Rate/Rule Reports > Benefit Rates
Rate Determination During Deduction and Cost Calculation (Batch)

These test scenarios exercise the shared DedCalc modules, which determine costs (deductions) based on NA Payroll parameters (pay group, pay calendar, deduction code definitions). 1. [Create a new rate table using the new key.] 2. [Attach the new rate table to an option in a Benefit Program.] 3. [Enroll employees in that option, covering a variety of key value and key availability scenarios, including a mix of covered persons if the key is based on personal biographics.] During Benefits Administration Option Preparation, or NA Payroll paycheck calculation, are expected amounts calculated? o o Benefits > Manage Automated Enrollment > Events > Run Automated Event Processing Payroll for North America > Payroll Processing USA > Produce Payroll > Calculate Pay
Note. The same shared processes are used for each product. Only one or the other product needs to be tested.
Rate Determination for Premium Reporting (On-line)

This test scenario exercises the rate management application classes used to calculate the total premium for rate-driven plans.
25
6/5/2007 [Use the same scenarios as for Deduction and Cost calculation testing.] Does the premium calculation run-phase produce correct total costs? o
Benefits > Interface with Providers > Snapshot Premium Report
Rate Determination for Employee-Specified Life Insurance (On-line)

These test scenarios exercise the rate management application classes used to retrieve a benefit rate for presentation to the employee. This occurs in eBenefits Enrollment when the employee is selecting a Life plan (employee-level or dependent-level) that is defined as employee-specified. For these types of plans the coverage amount (and therefore the cost) cannot be precalculated during Option Preparation, and must wait until the employee makes a positive election. 1. [Attach a new rate table to some employee-specified Life options (employee- or dependent-level) in a Benefit Program.] 2. [Enroll employees in those options.] 3. [Trigger events for these employees to allow access to eBenefits Enrollment.] When the employee selects an employee-specified life option, is the proper rate quoted for it? o Self-Service > Benefits > Benefits Enrollment
26
6/5/2007
Appendix A Validation and Feedback

This section documents that real-world validation that this Red Paper has received.
CUSTOMER VALIDATION
PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons learned from these customer experiences will be posted here.
FIELD VALIDATION
PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned from field experience will be posted here.
27
6/5/2007
Appendix B Revision History REVISION HISTORY

4. 12/12/06: Created document.
28
6/5/2007
Understanding Benefits Rates December 2006 Author: Gregory Beretta, Principle Software Developer, PeopleSoft Enterprise HCM Applications Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright 2006, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
29

RP e HCM Benefits Ra

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RP e HCM Benefits Ra

Caricato da

Copyright:

Formati disponibili

HCM Benefits 9.

0 - Understanding Benefits Rates

U N D E R S TAN D I N G B E N E F I TS R ATE S 6/5/2007

Chapter 4 - Calculation Rules .................................................................................................................................10 Calculation Rules Setup 10

Appendix A Validation and Feedback ..................................................................................................................27 Customer Validation Field Validation 27 27

Appendix B Revision History................................................................................................................................28 Revision History 28

Copyright 2007 Oracle, Inc. All rights reserved.

STRUCTURE OF THIS RED PAPER

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Chapter 2 - Goal of the New Rate Architecture

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Chapter 3 - Defining Benefit Rates

Covered Person Type

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Benefit Plan and Coverage Code

RATE KEY SOURCES

Covered Person Type

Character with prompt against Coverage Code Table.

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

BUILDING A RATE TABLE

Entering Rate Data - Keys

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Entering Rate Data - Style

Entering Rate Data Currency Code

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Chapter 4 - Calculation Rules

CALCULATION RULES SETUP

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Chapter 5 - Using the Rate Management Application Classes

CONTENTS OF PACKAGE BN_RATES

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Package: RateAccessMgmt Class: UserRateInput

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

SubPackage: CalcRulesMgmt SubPackage: DependentListMgmt

SubPackage: RateDefnMgmt SubPackage: GlobalBenefitRateMgr

USING THE BENEFITRATE CLASS

PeopleSoft Enterprise HCM Red Paper

Import the appropriate application packages and class definitions.

&oRateKeys = create BN_RATES:RateAccessMgmt:UserRateInput(); &oRateMgr = create BN_RATES:RateAccessMgmt:BenefitRate();

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Copyright 2007 Oracle, Inc. All rights reserved.

PeopleSoft Enterprise HCM Red Paper

Chapter 6 - Extending the Supported Rate Key Sources

ADD THE KEY AS SYSTEM DATA

BN_RATE_KEYS FieldName FIELDNAME

MODIFY RATE TABLE COMPONENT (UI) OBJECTS

PeopleSoft Enterprise HCM Red Paper

Create Work Fields