Temporary variable
In the expression:
C := DateOfBirth #DATEPLUS 65y &
C is a variable whose value is only accessible after it has been assigned and only within the expression where it's been assigned. It is temporary since this particular C has no meaning in other expressions.
Among the things you can assign to temporary variables are constants and the results of functions (e.g., #BEGMTH). For example:
A:= 1000 & ; assign 1000
B:= DOB & ; assign date of birth
C:= #BEGMTH B & ; round b to the beginning of the month
D:= 7/16/2008 & ; assign a date
E:= SALARY & ; in a Data Default this is a scalar containing the last value in the salary start/stop array field
F:= SALARY & ; in a transformation expression, this is calculation dates number of values; salaries appear on calculation dates that are
; equal to a stop date; if more than reported salary uses the same stop date, those values will be added together
G:= #DATE > 12/31/2010 & ; what calculation dates are after 12/31/2010 (e.g., transformation expression
H:= G * 1000 & ; 0 before 1/1/2011 and 1000 after 12/31/2010
I:= #ENDMTH #DATE & ; round every calculation date to the end of ; the month
J:= I #GETASOF #THIS & ; every value in a month is equal to the end ; of month value in #THIS
Note that #DATE and #THIS are available in transformation expressions, but not Data Default expressions.
Assigning database fields and the results of array operators to temporary variables may generate slightly different results depending on the type of expression in which the assignment is made (e.g., data defaults vs transformation expressions) and whether the database field is a scalar, effective date array, or a start/stop array
Scalars
If the database field is a scalar (e.g., a single value with no date dimension such as date of birth), then in most expressions the temporary variable will contain a scalar value: Selection Expressions, Service Rounding, Date Adjustments, Data Defaults, and Transformation Expressions. However, in Benefit Definitions, Accrual Definitions, and SubFormulas, you cannot use a database field -- you have to create and use a Benefit Formula Component Database Field component or an Accrual Basis Component Database Field component. Even if the underlying field is a scalar, the Database Field component turns it into an array with a calculation dates number of identical values. While this seems insignificant, it can cause problems. For example, when the left argument to #GETVALUE is a scalar date, then the value associated with that date is returned. In a transformation expression, DOB #GETVALUE xxx would return a zero because date of birth is almost never in the set of calculation dates. In Benefit Definitions, Accrual Definitions, and SubFormula expressions, you have to use a Database Field component which will contain an array of dates of birth (all the same), so DOB #GETVALUE xxx will return the last value in the array xxx. This is why we recommend using #GETASOF (instead of #GETVALUE) in Benefit Definitions, Accrual Definitions, and SubFormula expressions.
Start/stop date array fields
If the database field is a start/stop array field, the temporary assignment behavior varies among the expression types. For example, suppose your start/stop salary array contains these values:
Data Default expressions
If you assign your salary field to a temporary variable, C:= Salary &, in a Data Default expression, then the temporary variable will contain a scalar; the last value in the Salary array (e.g., 1200.00 from the 07/16/19 07/27/19 row). If you need all the values, you can use #VALUE or other array operators to create an array. Note that after the expression V:= #VALUE Salary &, V will be an array containing these 12 values: 3100.00 1500.00 1200.00 1400.00 550.00 700.00 800.00 500.00 600.00 3000.00 2700.00 1200.00.
Transformation expressions
If you assign your salary field to a temporary variable, C:= Salary &, in a transformation expression, then, because #DATE is available in a transformation expression, the array field is used to populate an array with a calculation date set of values, where each reported salary shows up on its stop date. Note how each start date, stop date and the day before each start date are added to the set of calculation dates. Also, because two salaries had the exact same stop date (7/27/19), the later value in the array was used (based on how the dates were sorted in the array). (If you want them added together, you probably want to handle that in a data default). Note that in an Estimate calculation, the last reported value will be projected (level) based on the Service or Salary Definition's measurement period (monthly in this example); in a Final calculation, there is no projection, so the values in red will be zero.
Benefit Definitions, Accrual Definitions, and SubFormulas
In Benefit Definition, Accrual Definition and Subformula expressions, you cannot use a database field -- you have to create and use a Benefit Formula Component Database Field component or an Accrual Basis Component Database Field component. When you create the Database Field component, you have the choice of returning the most recent value (i.e., a scalar which is turned into a calculation dates number of identical values) or all values (i.e., a calculation dates number of values). If a value's stop date is in the set of calculation dates, then the value shows up on it's stop date. If some values have the same effective or stop date, then the latest value in the array is used (based on how the dates were sorted in the array). (If you want them added together, you probably want to handle that in a data default.) If the stop date is not in the set of calculation dates, then the value are not shown. (If you need them to be shown, you need to add those dates to the set of calculation dates.)
Effective date array fields
If the database field is an effective date array field, then the temporary assignment behavior varies among the expression types. For example, suppose your RatesOfPay effective date array contains these monthly rate of pay values:
Data Default expressions
If you assign your rate of pay field to a temporary variable, C:= RatesOfPay & in a data default expression, then the temporary variable will contain a scalar, the last value in the RatesOfPay array (e.g., 3250.00 from the 03/22/20 row). If you need all the values, you can use #VALUE or other array operators to create an array. Note that, after the expression V:= #VALUE RatesOfPay &, V will be an array containing these 3 values: 3100.00 3000.00 3250.00.
Transformation expressions
If you assign your rate of pay field to a temporary variable, C:= RatesOfPay & in a transformation expression, then, because #DATE is available in a transformation expression, the array field is used to populate an array with a calculation date set of values, where each reported rate of pay shows up on its effective date and every date thereafter, until the next reported rate of pay (if any). Note how each effective date and the day before each effective date are added to the set of calculation dates. If two reported rates of pay had the exact same effective date, then those values would have been added together. (This is probably appropriate for reported salaries or hours, but not for date or coded fields, in which case, you probably want to handle that in a data default). Because this is an effective date array, the last value will appear at every date later or equal to the last effective date (i.e., the value in effect beginning with this effective date).
Benefit Definitions, Accrual Definitions, and SubFormulas In Benefit Definition, Accrual Definition and SubFormula expressions, you cannot use a database field -- you have to create and use a Benefit Formula Component Database Field component or an Accrual Basis Component Database Field component. When you create the Database Field component, you have the choice of returning the most recent value (i.e., a scalar which is turned into a calculation dates number of identical values) or all values (i.e., a calculation dates number of values). If a value's effective date is in the set of calculation dates, then the value shows up on it's effective date and every date until the next effective date, if any. If the effective date is not in the set of calculation dates, then the value shows up on the next available calculation date unless the next effective date occurs first. In either case, multiple values with the same effective date will be added together. (This is probably appropriate for reported salaries or hours, but not for date or coded fields, in which case, you probably want to handle that in a data default).Suppose the plan year is calendar year, and the set of calculation dates only contain end of plan years, decrement, and benefit commencement dates. Then, this is how the RatesOfPay effective date field populates:
Notice how the 1/1/19 rate of pay (3100.00) seems to disappear. It will only be seen if you add a calculation date from the range [1/1/19, 6/16/19].