Overview

A retroactive transaction is defined as a transaction whose Effective Date is less than the Effective Date of the most recent job history record.  The Retroactive Processing screen is used to reconstruct an employee’s history to properly reflect the effect of an original retroactive request.

“CN” (Conversion) Records

Records that have been carried over from LGMAST will have a Request ID beginning with “CN,” indicating that they are “conversion records.”  If any of the transactions involved in the retro process are conversion records, they must be updated before the new retro transaction can take place.  If they are not updated, the system will prompt you to do so before allowing entry of the retro transaction.

To update an employee’s conversion records, use the Query function to display their Job History.  Take note of the Effective Date of the retro transaction.  It will be necessary to update the record immediately preceding (chronologically), and any records following, the Effective Date of the retroactive transaction.  To update these records, do the following:

• Select each record by clicking on the circle to the left of the transaction, and click CORRECTION.  The detail screen of the selected transaction will display.

• Complete any required fields on this screen, if necessary, and click SUBMIT.  The Job History screen will display again.  Notice that the Request ID no longer displays a “CN” in the first two positions.

• Continue this process for all conversion records that need to be updated.

When all necessary conversion records have been updated, the retroactive transaction may be entered.

1. To begin the retro process, the appointing authority enters a request that is a valid type for retroactive processing.  These request types include:


• 02     – New Hires
• 03     – Conversions of Appointment Type
• 04     – Individual Transfers
• 05     – Organizational Transfers
• 06     – Separations
• 07     – Demotions
• 08     – Promotions
• 09     – Leaves of Absence
• 10     – Returns from Leave
• 12     – Static Job Information Changes
• 14     – Disciplinary Actions
• 17     – Individual Salary Adjustments
• 19     – Advancement Requests
• 94     – Laterals
• CM   – Changes in Compensation Method
• IT     – Intergovernmental Transfers


2. Based on the request Effective Date, the system will immediately determine if it is a retroactive request.  If it is, retroactive processing will be initiated.



  NOTE:  If an appointing authority does not have sufficient information during creation of the retro transaction, it may be Saved, rather than Submitted.  The status will be set to “Retro Incomplete” until the action can be finalized.

After submission by the appointing authority, the transaction will display in the inventory with a status of “Retro Review (HRM)” or “Retro Review (HRIS),” depending upon the type of transaction.  This original transaction will also be referred to as the “kick-off” transaction.



3. The action will then be reviewed by the appropriate division within CSC.  After review, one of four status may be assigned:  Returned, Pending Correction, Approved, or Rejected.  This is done by selecting one of these statuses from the Transaction Status drop-down box.



If approved by CSC, a retro package transaction is system-generated, consisting of the kick-off transaction, plus all subsequent employee history records.  This retro package transaction will appear on the inventory with a status of “RETROactive.”

If the kick-off transaction is disapproved, the transaction status is set to “Rejected,” and no further action is taken.

If the kick-off transaction is Returned, or is Pending Correction, normal processing procedures apply.

Once a transaction’s status is set to “RETROACTIVE,” the appointing authority may begin to process the retro package.  To do so, select the transaction from the inventory.

Sequencing Retroactive Transactions

Occasionally, two or more history records in a retroactive package will have the same Effective Date.  When this occurs, a Retroactive Package Sequencing screen will display after the transaction is selected from the inventory.

All transactions with the same Effective Date will display on a grid.  If necessary, click on either the “UP” or “DOWN” function next to the record that should be re-sequenced.  Keep in mind that a “1” identifies the first (earliest) record, a “2” the next record, etc.  The highest sequence number identifies the most recent record.

When the sequencing is completed, click SUBMIT.

After selecting the “Retroactive” transaction from the inventory (and completing the Retroactive Package Sequencing screen, if necessary), the Retroactive Processing screen will display.  This screen will show “kick-off” information (the transaction just entered) at the top of the screen; the bottom of the screen will display all history records with an Effective Date that is greater than, or equal to, that of the kick-off transaction.

  NOTE:  The complete kick-off transaction may be viewed from this screen by clicking on the “View Kickoff” button.

Rescinding the Retro Package

In the event that an entire retro package should be deleted, the appointing authority can delete it on this screen by clicking the RESCIND button.  The system will require a second prompt to confirm the deletion.

The retro package and the kick-off transaction are then deleted from the transaction file and will be removed from the inventory.

  NOTE:  The Rescind process is not applicable if the transaction status is “Retro Review 2.”

Updating / Deactivating History Records

Each history record will display on a separate line.  For each record in the retro package, the appointing authority may choose one of three options from the “Action” column’s drop-down menu:

Inquiry  -         This will display the detail information of the transaction.  No changes are permitted.

Update  -           This will also display the detail information of the transaction, but will allow the record to be modified.  Only those fields that were keyable on the original entry can be updated by the appointing authority.  Additionally, any fields that are changed will have to meet CAMPS editing procedures.

                              All other history fields contain the history carried through from the kick-off transaction, and are updated by the system as each subsequent approved transaction is processed.

Deactivate -  This selection will change the transaction from Active to Inactive by removing the record from the employee’s history file.  It will not delete the transaction from the CAMPS database.

Because the history records must be updated in chronological order, processing must begin with the earliest record (i.e. the record at the top of the screen).  Only one line at a time may be updated or deactivated.

1)   Beginning with the top record, select the appropriate Action status from the drop-down menu (Inquiry / Update / Deactivate).  Click the corresponding “Detail” box to the left of the transaction to display expanded detail information about the transaction.

2)   After making any appropriate changes to the detail screen, click SUBMIT.  The system will return to the Retroactive Processing screen, and the appropriate Status Code (80 = Approved; D = Deactivate , etc.) will display in the Status field to verify that the action has been taken.

Repeat Steps 1 and 2 above for each line of history.

Completing the Retro Package

After all lines of history have been adjusted, take a moment to review the Status column to insure that the correct action has been taken for all records.

If everything is in order, click the SUBMIT button at the bottom of the Retroactive Processing screen to submit the completed retro package.

After submission, the transaction will display in the inventory with a status of “Retro Review 2.”

When the transaction’s inventory status is “RETRO REVIEW 2,” it is ready for final Civil Service Commission approval.

A CSC employee will access the transaction, and either Approve or Reject the entire package.

If Approved, CAMPS will perform real-time updates to the employee’s job history with the records from the retro package file.  The retro package is not deleted at this point, but it is no longer available for update.  The kick-off transaction will be displayed on the inventory screen with a status of “Approved.”

If Rejected, the employee’s job history will not be updated, and the retro package transaction will be displayed on the inventory with a status of “Rejected.”  No further action is taken.

A new Request Number will be generated for each approved history record.  This new number will be similar to that of a regular transaction, except that the letter “R” will display in the 13th position to identify the transaction as part of a retroactive request.

The original transaction will be maintained on the history file with a job status of “Inactive.”  It will no longer be displayed on the Job History screen.