Accrual Basis Components

The Basis Formula portion of an accrual definition Benefit Formula Component is written as a free-form expression. In many cases it is a simple expression, but in others it may be of sufficient complexity to require components of its own.

These Accrual Basis Components are defined in the same manner as Benefit Formula Components. There are only a few differences to consider:

An Accrual Basis Component cannot itself be an accrual definition.
The analogous Benefit Formula Components would be projected to decrement, but Accrual Basis Components may be treated differently. They are themselves a part of the Accrual Basis, or Basis Formula (rather than the Accrual Rates), and the treatment of the basis is determined by the actuarial cost method (aka liability method). For example, calculations under the pure unit credit method will not project any Accrual Basis Component values.
As a consequence of the second point, some parameters available for table lookups in Benefit Formula Components are not applicable to Accrual Basis Components.

All Accrual Basis Component definitions have three parameters in common:

Name must begin with a character and may consist of characters, numbers and underscores. When naming an Accrual Basis Component with the end result of a date, adding the three characters _DT to the end of the component’s name will display the date in readable date format in the sample life output.

Description can be a phrase of any length and may contain any character or symbol.

Component type indicates the class of Accrual Basis Component of which this object is a member. The rest of the screen will change to present only the parameters that apply to this type of Accrual Basis Component.

Accrual Basis Components may be any of the following types:

Constant

This type of component may be either a constant value entered as a numeric value or Plan Constant for all records, or a value that depends upon the contents of a coded field in the database. As numbers may be typed directly into the Basis Formula, you should create a component with a constant numeric value for all records only if increase rates are to apply. A component that varies by coded field is useful when the component’s value varies among different divisions but the structure of the accrual basis formula is the same.

Constant value is the single value on the valuation date for all records. Any numeric value or Plan Constant may be entered.

If the value of the component on the valuation date Varies by coded field, the contents of this field will determine the value assigned to the Accrual Basis Component. Select from the list of coded database fields in the current Project’s Data Dictionary. The codes for the field will populate the first column of the spreadsheet that becomes accessible. The spreadsheet will map the codes of the field to the related values you enter in the second column for the Accrual Basis Component. Any numeric value is allowed.

If a component’s value depends on the year in which the decrement occurs, check the Apply increase rates to this component box to prompt a question about those increase rates in the Valuation Assumptions and Projection Assumptions sections of the Input menu. Increase rates may be entered as constant or calendar year dependent (varying by calendar year of decrement) or may refer to increase rate tables.

Database Field

This type of component may be either a database Field or a database Expression. Because accrual basis formulas do not refer directly to database names, create a component of this type to incorporate a reference to one or more database fields. You may then refer to the component in the Accrual Basis Expression of an accrual definition. Alternatively, you may type the database field name into the expression box for the Accrual Basis; ProVal will offer to create the component for you, by reference to the database field of the same name.

When the component is a database Field rather than a database Expression, the ability to give the Accrual Basis Component the same name as the underlying field is particularly useful. If the Data Dictionary field referenced is a date, the sample life output will display the date in readable date format, instead of in numeric format (i.e., instead of displaying the number of days since 1/1/1900).

When the component is a database Expression, this type of component simply evaluates an arithmetic expression and returns the answer. The value returned will be constant over time. Consequently, fields that contain age, service or pay receive no special treatment. If any date-type Data Dictionary fields are referenced in the Expression, the sample life output will display them in date format, instead of in numeric format (i.e., instead of displaying the number of days since 1/1/1900).

Select the database Field to which this Accrual Basis Component refers. Only numeric and date fields in the current Project are included in the list. Or you may click the New button to create a new database field for selection.

Instead you may select the Expression option; enter in the box the database expression itself, which may include any number of database fields. Pressing the F1 key when the cursor is in this box will summon a list of useful information, including the field names and available operators. Refer to the fields by simply typing their names. Database expressions may contain logical statements, which are evaluated as 1 if true and as 0 if false.

Use the Selection Library button to incorporate into your database expression a Selection Expression that you have already created and saved under the Selection Expressions command of the Database menu. Click this button to enter the Retrieve Selection Expression dialog box, in which you Pick a selection expression to retrieve from the library of expressions in the current Project.

SubFormula

This type of component allows you to reference other Accrual Basis Components by use of an expression composed of Accrual Basis Components and expression operators. The component simply evaluates the expression and returns the answer; it is useful for complex accrual basis formulas that are repeated in several accrual definitions, because the need to edit a formula in several places, instead of just one, is avoided.

The SubFormula box contains the expression itself, which may include any number of Accrual Basis Components. Pressing the F1 key when the cursor is in this box will summon a list of useful information, including the component names and available operators. Refer to the components by simply typing their names. SubFormula expressions may contain logical statements, which are evaluated as 1 if true and as 0 if false.

Table

This type of component may be either a single Benefit Component Table for all records or a collection of tables chosen according to the contents of a coded field in the database.

The Accrual Basis Component looks values up from the specified Benefit Component Table(s). Tables can include dimensions for age, service and sex. Note that, in OPEB mode as well as the pension modes, the age and sex for lookup are always the plan member’s age and sex, although you may be defining a benefit payable to the spouse or to a dependent. In all modes, service lookup is the member’s service at decrement.

An Accrual Basis Component of the table type can be used, in the pension modes, to model a schedule of age-graded cash balance credits, and, in OPEB mode, to model declining face amounts of insurance after retirement. In the latter situation, this would be accomplished, typically, by representing retirement age as a Benefit Formula Component of the “Accrual definition” type that is Basis only, using an age-based table returning its index for the (sole) Accrual Basis Component.

Pick the associated Single table for all records from the list of Benefit Component Tables already defined in the current Project, or click the button to access the Benefit Component Table library. From there you can create new tables or modify existing ones.

If the component value Varies by coded field, the contents of this field will determine the table used to assign a value to the Accrual Basis Component. Select from the list of coded database fields in the current Project’s Data Dictionary. The codes for the field will populate the first column of the spreadsheet that becomes accessible. To assign values to the Accrual Basis Component, choose the table (from among the list of all the Benefit Component Tables in the current Project) related to the field code. The spreadsheet will map the codes of the field to the selected tables. To modify a table in the list or create a new one, click the button to access the Benefit Component Table library.

The Table service based on parameter is used to define service for look up if the table has a service dimension. The preset option, “<rounded attained age – rounded hire age>”, is displayed; this option indicates that service will be computed as the difference between rounded attained age (as of the decrement date) and rounded hire age. This treatment is the same as ProVal’s treatment in versions 2.21 and earlier versions, in which it was not possible to choose a database field to define table service. (See also the discussion of the Date of hire (or hire age) parameter under the Active Data topic of the Census Specifications.) Alternatively, table service may be based on a database Field; select from the list of database fields in the current Project. You may refer to a date field from which to measure service or to a numeric field containing service as of the valuation date. Note that selecting, by name, the date of hire field of the Active Data topic of the Census Specifications might not produce the same result as the preset option. This is a consequence of the fact that if a database field is selected, truncated service based on the field is used. That is, if you select the date of hire field by name, ProVal subtracts the hire date from the decrement date and then truncates. The result may be lookup service of one year more or less than if the preset option were used. For more information about table lookups, see the discussion of table interface. If you need fractional service accruals (e.g., hours-related service) or rounding (e.g., completed years), select from the library of Service Definitions. The button accesses the library to create and modify Service Definitions.

ProVal’s default is to compute age for table lookups as the rounded attained age at each valuation date anniversary, i.e., the age on the birthday nearest the valuation date. For example, if a plan member was born on 5/15/1960 and the valuation date is 1/1/2013, the member’s age is 52 years, 7 months and about 15 days on the valuation date. For most valuation purposes, such as determining applicable decrement rates, ProVal deems the member to be age 53, which is the exact age on 5/15/2013 (the nearest birthday to 1/1/2013). In the pension modes, the Table Age button provides the option to look up values of the table component using a different definition of age. To keep ProVal’s default for determining age for look up, select Age nearest birthday for the Table values based on parameter, and the value returned for lookup at the valuation date will be the tabular value for age 53. To use instead the age on 5/15/2012, the birthday preceding 1/1/2013, select Age last birthday, and the value returned for lookup at the valuation date will be the tabular value for age 52. If Age in years and months (interpolated) is selected, the member’s age at the valuation date, 1/1/2013, is deemed to be age 52 and 7 (completed) months, and the table value “looked up” at 1/1/2013 will be the sum of 5/12ths of the age 52 tabular value and 7/12ths of the age 53 tabular value (i.e., we interpolate the member’s age between 52 and 53, to derive a more exact age at 1/1/2013). Note that if the member’s birthday is on the valuation date, these three options will use the same age for looking up table values. Finally, if Year minus year of birth is selected, the valuation date value will be the tabular value for age “2013 minus 1960”, that is, for age 53.