Defining how reported and projected salaries should be allocated
Question: How can I define how reported and projected salaries should be allocated?
Answer: Use the allocation parameters within the Allocate and reflect salary topic of a Salary Definition. These parameters allow you to control how reported salaries (i.e., as defined in the Salary History Definition) were accrued and how projected salaries will accrue.
How is a reported salary measured or weighed?
ProAdmin uses a salary’s start and stop dates to determine its “weight” or fraction of the measurement period: the amount of service earned from the salary’s start date to its stop date (inclusive, notationally shown as [start date, stop date]) divided by the amount of service earned in the measurement period containing that salary. When a salary's start and stop dates are in different measurement periods, ProAdmin uses as many measurement periods as needed to cover the salary. For example, suppose that the salary measurement period was monthly and $17,000 was earned from 9/17/2015 to 11/21/2015. Then the weight or fraction for September is defined as the service earned in [9/17/2015, 9/30/2015] divided by the services earned in [9/1/2015, 9/30/2015] + [10/1/2105, 10/31/2015] + [11/1/2015, 11/30/2015]; the October fraction is the service earned in [10/1/2015, 10/31/2015] divided by the services earned in [9/1/2015, 9/30/2015] + [10/1/2105, 10/31/2015] + [11/1/2015, 11/30/2015]; and the November fraction is the service earned in [11/1/2015, 11/21/2015] divided by the service earned in [9/1/2015, 9/30/2015] + [10/1/2105, 10/31/2015] + [11/1/2015, 11/30/2015].
For the following discussions, suppose the salary measurement period is calendar year, the plan year is calendar year, and only one salary has been reported: $20,000 with a start date of 9/17/2015 and a stop date of 11/30/2015. In each case, the discussion centers upon how different definitions of the service weighted measurement period Service Definition Set would affect the resultant salaries. In particular, assuming that the service weighted measurement period Service Definition Set calculates service based on elapsed time, how would the combination of different measurement period and elapsed time parameters options in the Service Definition affect the salaries?
How would calendar days measure salaries?
If $20,000 was earned for the period [9/17/2015, 11/30/2015], then we know that there are 365 calendar days in 2015 and there are 75 days in the period [9/17/2015, 11/30/2015] (1 + 11/30/2015 – 9/17/2015). The weight or fraction of the measurement period is 75/365, or 0.20547945205479451 (18 significant digits). If we needed to determine an annual salary for projection, then using calendar days, we would calculate $97,333.333333 as the annual salary: $20000 * (365 days in the year) / (75 days in the period [9/17/2015, 11/30/2015]). Once we know the annual salary, we can then project what salary will be earned in the period [12/1/2015, 12/31/2015]: $8,266.666667 = $97,333.333333 * (31 days in December) / (365 days in the year).
You would parameterize this allocation by referencing a Service Definition with an annual measurement period and an elapsed time calculation method based on true calendar days.
How would fraction of months (based on days in month) measure salaries?
The fraction of a full month’s salary is 1 (or 100%), the same for each full month, no matter how many days there are in a month (28-31 days). So, each full month’s salary is 1/12 of the annual amount. The fraction of a partial month’s salary, using calendar days, is the days the salary covers in that month divided by the actual days in that month. So, how do we handle $20,000 for the period [9/17/2015, 11/30/2015]? We can look at the $20,000 as being earned evenly over 3 periods: [9/17/2015, 9/30/2015], [10/1/2015, 10/31/2015], and [11/1/2015, 11/30/2015]: { (14 days of salary earned in September) / (30 days in month of September) + 1 month for October + 1 month for November} / {12 months in a year}, (2 + 14/30) /12, or 0.205556 of a year. Now, the annual salary is $97,297.297297 = $20,000 / 0.205556 and for the period [12/1/2015, 12/31/2015], $8,108.108108 will be earned ($97,297.297297 * 1/12, because December is a full month of salary).
You would parameterize this allocation by referencing a Service Definition with a monthly measurement period and an elapsed time calculation method based on true calendar days.
How would nearest half-months (the default salary allocation methodology) measure salaries?
Each full month is 2 half-months and 9/17/2015 rounded to the beginning of the nearest half month is 9/16/2016. So, [9/17/2015, 9/30/2015] is 1 half-month, [10/1/2015, 10/31/2015] is 2 half-months, and [11/1/2015, 11/30/2015] is 2 half-months. So, the $20,000 was earned over 5 half-months or 5/24 of a year, which means the annualized amount is $96,000 ($20,000 * 24/5). And, $8,000 will be earned for the full month of December ($96,000 * 2/24).
You would parameterize this allocation either by using the default allocation or by referencing a Service Definition with a semi-monthly measurement period.
Verifying a Service Definition Set measurement of salaries
Each of the scenarios above of using calendar days to “measure” salaries referenced a Service Definition Set. Here is an example of what the Service Definition Set results would look like that used calendar days to measure salaries, starting with a discussion of the service calculated at several key dates:
Date |
Service (based on calendar days) |
12/31/2014 |
10.00000000 |
01/01/2015 |
10.00273973 |
… |
|
09/16/2015 |
10.70958904 |
09/17/2015 |
10.71232877 |
... |
|
11/30/2015 |
10.91506849 |
12/31/2015 |
11.00000000 |
01/01/2016 |
11.00273224 |
Note that the service at each date includes the service earned up to and including that date. For example, service earned in [1/1/2015, 1/1/2015] is 1 day of service, or 1/365 (0.00273973), and the service earned in [1/1/2015, 12/31/2015] is 365 days of service, or 365/365 (1.00000000). The service calculation results summarized in the table above used a hire date of 1/1/2004 and assume 1 day of service was earned for each day. That is why there are exactly 10 years of service at 12/31/2014 rather than 9.997260274 (which is 10 years - (1 day not included) / (365 days in the year) or 9 years + (364 days before 12/31/2014) / (days in the year)).
From the above table we can see that there is 1 year of service earned in 2015 (11 years of service on 12/31/2015 – the 10 years of service on 12/31/2014). Also, the service earned for the period [9/17/2015, 11/30/2015] is 0.20547945 (10.91506849 on 11/30/2015 - 10.70958904 on 9/16/2015). So, now the annual salary is $97,333.33431 ($20,000 / 0.20547945), and $8,266.667056 is projected to be made during December, $97,333.33431 × (11.00000000 on 12/31/2015 - 10.91506849 on 11/30/2015). Remember, the service 10.70958904 on 9/16/2015 represents the service earned from 1/1/2004 thru 9/16/2015, and includes any service earned on 9/16/2015. That is why we used the 9/16/2015 service rather that the 9/17/2015 service (because the 9/17/2015 includes 1 day of service earned on 9/17/2015).
Why was $97,333.33431 the annual amount using the Service Definition Set and $97,333.333333 the annual amount using straight calendar days? The difference is strictly due to rounding! ProAdmin only shows 6 decimal places in the Detailed Service Definition Results, so when we used the service shown in the Detailed Results (i.e., rounded to 6 decimal places) we calculated $97,333.33431 as the annual amount. But in reality, ProAdmin would have calculated $97,333.33333 as the annual amount. However, since ProAdmin only shows salaries with 2 decimal places, $97333.33, we might have not have noticed any rounding difference (for this example).
Please see How to set up a Service Definition Set to allocate/project salaries for a detailed description (and suggestions) of how to set up this Service Definition. Also, please check out these other allocate and project salary examples:
Allocate reported salaries based on date of hire anniversaries
Allocate reported calendar year salaries and project salaries on a bi-weekly
basis
Allocate annual salary amounts into user-defined half months for monthly salary
Projecting flat bonuses and increasing salaries