Modular Approach to Rules
Pension Administration takes a modular approach to setting up calculation rules. Use different modules to establish:
A calculation rule that is based on one of the core functions. This is a definition module.
A calculation rule that is based on who uses the rule. This is a group module.
When you put together a complete rule, you mix and match definitions and groups to specify who uses which calculation method and when.
This diagram shows the architecture for setting up the plan calculation. The calculation is made of plan components, or function results. Those plan components are, in turn, made up of three elements. Definitions provide the calculation methods, or the “how” for the calculation. Groups provide the “who” criteria that controls which employees use each definition. And effective dates control the “when” for each definition, since different definitions can be used at different times.

For example, assume that your plan vesting rules change from seven-year step vesting to five-year cliff vesting in 1980. Employees hired before January 1, 1980 can use the better of the two rules; those hired afterwards must use the five-year cliff vesting.
Your complete rules have two effective dates. First, from the inception of the plan until 1980, there's one rule (step vesting) available to all employees. Second, after January 1, 1980, employees hired after the change use the new rule (cliff vesting) while employees hired before the change use the better of the two rules.
You need to set up the following modules:
Vesting definition 1: Seven-year step vesting.
Vesting definition 2a: Five-year cliff vesting.
Vesting definition 2b: Better of the two vesting methods.
Group 1: All employees.
Group 2: Employees hired January 1, 1980 and later.
Group 3: Employees hired before January 1, 1980.
Note: In reality, each of these modules would reference other modules.
Your rule should look something like this, with the effective and vesting dates as in the example below:
This diagram illustrates the preceding scenario. There are two effective dates for vesting calculations. The first effective date has a single rule for all employees. The second effective date is the date of the rule change. It has two rules: one for employees hired before the rule change, and one for employees hired after the rule change.

You put all the pieces together on the Function Result page. Function result refers to the complete instructions for calculating the result for a function. Remember, the definition alone isn't enough because several definitions may be used in different situations.
You create function results for all the core functions that apply to your plan. Certain functions normally have just a single function result in the plan. For example, your plan only uses one plan eligibility function result because for each employee, there is only one plan eligibility value.
Other functions may have multiple function results:
If your plan calculates participation service, vesting service, and plan service separately, you would use three service function results: one for each type of service you need to calculate.
Benefit eligibility usually uses several function results: for example, one to determine eligibility for normal retirement, one for early retirement, and one for disability retirement.
The plan may provide more than one benefit amount function, provided by the benefit formula.
Note: During implementation, you must track many modular objects: function results, definitions, and various definition subcomponents. This task is easier if you develop a naming standard for your pension objects. For example, you may want to set aside the first or last characters to identify the object type, ending all function results with "_F" and all definitions with "_D". You may also incorporate a plan code into the name so that you know which plan uses that object. The naming standard has a ten-character limitation.