Contract Pay Assignments
What is meant by stopping and starting an assignment?
Stop and starting an assignment refers to the process necessary to make changes to how pay assignments are assigned to employees. A stop and start means that as of a given date a change has occurred. It is necessary in these cases to stop the existing assignment on the appropriate date and start a new one on the date the change occurred including that change. The reason for this is that at any given time frame you would be able to look at the pay assignments and be able to see what should have happened. If this was not true it becomes impossible to know what the effective salary, earnings, distributions, etc. where at any given time.
When do you start and stop assignments?
You start and stop assignments whenever a change occurs that affects how a pay assignment is calculated, distributed or detailed information required for reporting changes. A general guide to follow is if you are not sure to stop and start and assignment it should always stopped and started. The reason for this is that it does not hurt to have extra detail. It is better to error on the side of caution than change an assignment and not be able to predict what should have been done as of a given date.
What is Escrow?
Escrow is difference between what an employee Earns and gets Paid in a particular time frame. For instance, an employee may Earn $1200 in a given month but only get paid $1000. The remaining $200 of earnings becomes escrow and is owed to the employee and is called Escrow.
What is Spread Pay?
Spread Pay is a mechanism that pays out existing escrow to the employee over a specified time frame or all at once. Spread Pay is usually invoked when a change occurs in an employee's salary or earnings. Spread Pay is signified by using the payout type on the assignment.
When Should Spread Pay be used?
Spread Pay should be used when a change occurs in the salary or earnings and it becomes necessary to pay the employee a new salary. A good example is when an employee gets a raise and their salary increases from $1000 to $1100 a month.
How are rates and salaries related? In the beginning of a contract an employee's earnings are a result of total hours worked on the assignment times the rate. The result of this calculation is the total earnings for this assignment. The salary of the assignment is calculated by taking the total earnings and dividing by the number of periods it is effective. If the total earnings is $1000 and the assignments is effective for 10 months then the employee should get paid $100 per period. That $100 is the salary of the assignment. This should be fairly straight forward however it gets complicated when the change occurs in the middle of the contract.
An example:
Employee Abbe is a teacher that works 10 months out of the year but gets paid all 12 months. The employees yearly contract is 24,000. To make the example easy we will assume they earn 2,400 a month and get paid 2,000 a month. The following equation represents how total earned should equal total paid over the whole contract.
Earnings per month * Number of Months worked = Salary * Number of Months Paid
We will assume that after 6 months the employee gets a raise to earn $2,600 a month. This means that after this change there are 4 earnings months left at $2,600 for a total of $10,400. Putting this in the equation above yields
2,600 * 4 = ? * 6
From this equation it is easy to see that the new salary is 1733.33 given how we calculate earnings and salary for each assignment. Does this seem correct? The employee received a raise but their salary went from $2,000 to $1,733.33. Something definitely seems wrong. Therefore, one must ask if this is the employee's complete salary. The answer is no because over the first 6 months the employee earns $14,400 and only gets paid $12,000. This means that the employee has 2,400 in escrow that they are owed. This escrow becomes spread pay when the change occurs. It is up to the site whether this Spread Pay Amount is paid to the employee in lump sum or over the remaining part of the contract. Typically, it is paid over the remaining contract and that is what we will do in our example. Therefore the $2,400 is spread over the remaining 6 months meaning that the actual salary of the employee is 1733.33 + 2,400/6 or 2133.33.
A simple table will show that these numbers are correct:
Earned Paid
First 6 Months 14,400 12,000
Last 6 Months 10,400 12,800
---------------- -----------
Total 24,800 24,800
From these results we can see that the employee gets paid correctly. Hopefully it is also apparent why stopping and starting the assignments is so critical. The current salary is a result of the difference of earned and paid over the original time frame. Even though escrow is stored in an accumulator several utilities are required to re-figure out what these numbers were when they were assigned. The standard Retro and Correction processes are two such utilities and require that an employee's contract be represented by assigned pay assignments.
An employee Experiences a Rate Change
The reason for the rate change really does not matter. It could be a step increase, a grade change, experience upgrade, calendar change, etc. Any change that affects the employee's earnings or salary can be considered a rate change and the result is typically the same. The current employee's assignment will be stopped and a new one with the correct rate, calendar, step, etc. will be assigned as of the effective date. Since a rate change means that the earnings/salary changed spread pay would be used to compute the correct salary.
Scenarios that fit into the "Rate Change" category are below. If any of these fields change they can loosely be called a rate change:
Salary
Rate
OT Rate
Effort
Pay Begin Date
Pay End Date
Calendar
Hrs/Day
Cal. Percent
Patch Type
Patch Begin Date
Patch End Date
Retro Date
The Employee Experiences a Change to the GL-KEY
This change is a little more complicated but it also results in the stopping and starting of the pay assignments. The reason for this has to do with two factors. The first is that the GL-KEY directly results in how dollars associated with this line are distributed to the general ledger. If we were to change this field, then any future dollars reported against the old line would be reported to the wrong GL-KEY. That is definitely unacceptable so we need to track when the GL-KEY change occurred. The second factor has to do with the payroll NUM-CD. This is the number assigned to the complete Pay String. Earnings are all charged to the NUM-CD in which they occur minus any exception entry (timecards). If we were to change a piece of the Pay String, and it does not matter which piece, then the NUM-CD will change. When this happens, the system cannot associate what timecards were originally assigned to that Pay String and which were exception entries. Because of this inability to determine where hours came from we would be unable to retro or correct any prior problems. Since that is unacceptable it is required to maintain a history of the assigned Pay Strings. Failure to do so will result in a system that can't look to the past which is required for corrections and retros. Any change to any of the 18 possible parts will result in this same change.
The employee experiences a retro
First one must understand what a retro is. A retro is a salary or earnings change that takes effect in the past. If we apply what we know about rate changes then that means that we need to stop and start the existing assignment and invoke spread pay. That takes care of the time frame from the current period forward. However, this is a retro and implies that prior periods also need to be adjusted. This is simply done by supplying a retro date on the pay assignment. This date is the date when the change went into effect. By running the standard Retro utility, the software will re-figure what was earned and paid on the old assignment and compare it to what should have been earned and paid using the new information supplied by the current assignment. The difference between what was earned and paid and what is now calculated is Retro Earned and Paid and given to the employee. Therefore, a retro is no different than a change in earnings or salary with a prior effective date or retro date.
There are two ways to make a retroactive change. Either the rate and salary are fixed, meaning that the rate and salary of the new assignment apply to all of the older assignments or the new and old assignments are related by a retro factor. A retro factor is simply a multiplier that will alter the rate and salary amount. For instance, if you wanted a 10% increase you would put in a factor of 1.10. Then the software will take the old rates and salaries and multiply them by this new factor giving a 10% increase. If the retro factor field is left blank it will default to doing the old fixed rate and hour method.
An Employee Terminates
In this case the employee is getting their final check. However, how do we know what the employee should be paid? Obviously, they should receive their last paid installment but is that all? The answer is no. The employee is owed their escrow balance. This is accomplished by putting a "PF" in the payout code on the pay assignment that is being terminated. If the employee is terminating completely then all affected assignments will need a code of "PF." This code causes a Calc Code to run in the system which pays off all escrow. One thing to note is that escrow in our system automatically includes spread balances. This means by paying out escrow, all spread balances are also being paid off. It is also important that the payoff code runs after all earnings have happened. The reason for this is so the earnings in the current periods are also paid out. It would be bad to have the payoff run before the earnings were considered. That would mean that the employee's final earnings would be stranded in escrow and result in an incorrect final payment.
An Employee Changes From One Contract to Another Midstream
This case is different from the rest because it is handled in two parts. First, we have the new assignment. It is handled just as that. As of the date given the assignment is assigned with the correct salary and earnings for the period that it covers. There is no trick to this assignment. However, the second part is not as straight forward. The first contract is done which means that there will no longer be earnings of new salaries given. This doesn't mean however that the contract is finished. If we look at the old contract it is quite possible that it has an escrow balance. Because the employee has earned money that is not paid, it becomes necessary to payout this escrow. To do this, end the Paid Dates and Patch Dates but leave the Effective Dates open. One may wonder what the point of this assignment is but that becomes clear when we use the appropriate code in spread pay. This code will pay the remaining escrow out over the given time frame thus paying out all remaining escrow dollars without having to create a secondary assignment.
Employee Experiences a Retro on an Assignment with Distributions
If you have an employee who has a 60/40 split on assignments and want to retro both assignments, special care needs to be taken. Since both of these splits have the same Contract ID, record type is used for further delineation as to what new pay lines pertain to what distribution lines. For instance, if you retro'd these assignments and the distribution percentages stayed the same, you would want the retro amounts on the new 60% line to retro back on the old 60% line and the same for the 40% line. To accomplish this, we identify how distributions relate by using the Record Type. Basically, when a retro is identified, the new amounts are applied to all pay assignments with the same contract and Record Type for the time frame between the retro date and the start of the new assignment. If the Record Type on the new assignment can't match the old assignment, a miscellaneous code can be used to specify the Record Type to be retro'd. This miscellaneous code is specified in common code PYFG/PY211C Associated Value 1. Even if you are doing a retro with no distributions the old and new assignments must match by record type.
Retro's using LWOP (Leave without Pay)
Typically, retros that involve LWOP will require two things. First the LWOP will need to be adjusted by the retro amount and secondly that adjustment will have to affect the retro paid calculation. Since LWOP typically affects earned and paid for the contract (along with a host of other hours) a special identifier was needed. The identifier is an "L" in switch 28 of the CDH definition. This will process the hour code to figure the retro amount for this CDH and then turn around and use that result directly in the retro calculation. Another caveat of LWOP is that typically the contract paid CDH is reduced by occurrences of LWOP. This reduction is typically handled in the Calc Code; however, the amount of LWOP that is a result of retro should not reduce the contract paid amount. The best way to void the unnecessary reduction is to use the alternate CDH code. The alternate CDH code can be used with those CDHs identified with an "L" or "E" in Switch 28. Common code PYFG/RETROEX1 allows you to specify the original code the occurrence happened and the code the retro software should generate any adjustments on. Once this is done the Calc Code can be modified to add the retro adjustment back into the contract paid (since it was over reduced when LWOP was taken out).