1) Currently, the system does not associate start and end dates with the Wage Scale Plans/Steps, and the system does not allow you to upload a Wage Scale Plan (that matches the system template).

2) There is also no "copy" function to copy the previous "Wage (Scale) Steps" and utilize the mass "% increase" function for annual across-the-board increases (like for cost of living). As such, we cannot use the mass % across-the-board feature, because we do not want it to overwrite the wage scale history, and we can't copy the previous scale and apply the increase to it.

3) Because we can't upload a Wage Scale Plan/Step, and our Wage Step Pay Rates increase every year, we have to manually create a "Step Plan" (and include the year in the name) in order to be able to select it in Compensation as a dropdown list option.

i.e. In our old system, each year the Annual Wage Scale Step was uploaded (each year) with an effective date range, so the system would automatically update the rate for any new entries. Of course, we still had to manually create a new (dated) entry on the Job Code, and Position Code, in addition to the new Compensation record, so that the records would align in the history, but that was once a year.

4) The old system 's "Job Code's" "Grade" ("Level") would also have effective start and end dates, so the Min ("Low Threshold") and Max ("High Threshold") pay rates on the "Job Code" would be updated every year. However, the way the Compensation is set up on the Job Codes in this system does not allow that. If there are no effective dates, then what is the purpose of the Min ("Low Threshold") and Max ("High Threshold")? There is also no export report function to indicate the Wage Scale Steps and Min and Max (for all job codes) and no effective dates, so in essence as it stands now, the "Min" would have to be the minimum starting pay at the beginning of the historical records, and the "Max" would have to be flexible enough to accommodate future pay increases, which defeats the purpose that it was intended for.

6) The purpose of assigning Grades ("Levels") to the "Job Codes" also is intended to prevent users from inadvertently assigning the wrong grade to a position. However, the system does not work like it should in this regards. For example, our positions have histories with different tiers/classifications of titles (like a "I" or "II" version of the same position, which is associated with different pay grades). The way the process is supposed to work is that we assign one grade to a "Job Code" and then when we plug that "Job Code" into the "Position", the new "Grade" ("Level") should be associated with it on the "Compensation" menu.

However, we ran into issues, and found the only solution that would get the "Change Compensation/New Compensation Action" menu to work was that we had to add the Grades ("Levels") for all "Job Codes" that were assigned to the "Position" in the it's history onto all related "Job Codes", so that they now list multiple grades instead of one. i.e. If a position had a "Nurse I" and a "Nurse II" in it's history, then both Nurse "Job Codes" had to have the Grades ("Levels") for both "Nurse I" and "Nurse II" in order for Compensation to work. I think part of this is because there are no effective dates assigned to the Grade/Level.