HR - Corrections Job Aid

GENERAL DESCRIPTION:

Correct History mode allows access to view, change, delete, and insert rows of data, regardless of the Effective Date. You must have Correction Access in your security role to make corrections. The button on the pages to allow updates to any and all data is labeled "Correct History." This process is also described as "correction mode,"correction access" or "correction".

PROCESS CONSIDERATIONS:

You may click on the links below to navigate directly to a section:


PROCEDURE STEPS:

Definitions

Current Row = The last, effective-dated row that is equal to or less than (<=) today's date. There is always only ONE "current row". To correct the Current Row, you can insert an effective-sequenced row and do not need to be in Correct History mode.

Future-dated Row = Any and all effective-dated rows that are greater than (>) today's date. To correct a Future-dated Row, you do not need to be in Correct History mode unless changing a 'key' field (see below).

Historical Rows = Any row where the Effective Date is less than (<) the "current row". To "correct" a Historical Row by inserting an effective-sequenced row, you must be in Correct History mode.



Key Fields

  • Job Data
    • Empl ID
    • Empl Record
    • Effective Date
    • Effective Sequence
  • Personal Information
    • Empl ID
  • Position
    • Position Number
    • Effective Date


Making Changes Without Correction Access



Purpose/Reasons for When Correction is Required (on Job Data and/or Position Management)

  • Inserting effective-dated rows in between other rows, less than the current row. This could be needed only on Job Data rows and/or Position Management rows.

    Job Data Example (not affected by Position Management): The current Effective-dated row is 08/01/2017 and the employee's prior row is 04/30/2017 (considered one of the Historical Rows). The person has a Pay Rate Change effective 06/01/2017. You must scroll to the 04/30/2017 row to insert a new row with an Effective Date of 06/01/2017. Since the 08/01/2017 row is Current, you must be in Correct History mode to insert the 06/01/2017 row.

  • Changing a "key" field. This could be needed only on Job Data rows and/or Position Management rows.

    Example: An employee is being entered with a hire date in the future (any date greater than today's date). It is then determined the employee won’t start until one week later than the original hire date entered. Since Effective Dates are key fields, you must be in Correct History mode to change this date.

  • Deleting a Position Management row (exception only). Although rows should not be deleted, there may be instances where you need correction mode to delete a Position Management row.

    Example: When you put someone on a Partial LOA and later determine the person should not have been put on an LOA, you cannot sequence a Return from LOA row to bring them back (there is no sequencing rows in Position Management). The only way to have this accurate on Position Management would be to delete the row. However, the row in Job Data should not be deleted.

  • Deleting a current or historical Job Data row (exception only).  Although Job Data rows should not be deleted, there may be instances where correction mode may be necessary to delete a row. 

Example:  When an employee needs to be terminated retroactively and there are current/historical Job Data rows after the termination effective date.

Deleting/changing Job Data rows using Correct History can have serious downstream impacts in Benefits, Time and Labor, and Absence Management.  When submitting a ticket that requires Job Data row deletion, the Service Center will also conduct a review to determine if the Job Data change has a Benefits/Time and Labor/Absence Management impact and fix accordingly.  



Impacts of Using Correction

  • Changing departments directly on a historical row
    • Making changes after a payroll has passed will impact SFS and Budget. A sequenced row should always be entered to update this scenario.

  • Changing compensation rates on a Historical Row
    • You will not have an audit trail of what the compensation actually was for that payroll, as well as no audit trail for SFS and Budget. A sequenced row should always be entered to update this scenario. If the sequenced row is added to a Historical Row that has multiple rows after the date entered, the "ripple" logic will apply and additional rows will automatically be put in to update subsequent compensation. See HR - Ripple

  • Any changes on Personal Information or Job Data pages can potentially have downstream impacts, which is why we must always abide by the decision UW has adopted for the use of correction mode.

To the top

ADDITIONAL RESOURCES

Related KBs:

Related Links:

To the top