Reversing Previous Results

There are several situations in which the system does not calculate retro deltas by subtracting old values from new values. In these situations, to calculate the deltas, the system reverses the old results and cancels prior calculations. The system adds the resulting negative values to any new values that may have been generated for the period (as long as they share the same payment keys) and moves the results to the current period (if the retro method is forwarding).

Reversal occurs when:

• The segment dates of the recalc period don't match those of the prior period.

• The payment keys of the recalc period/segments don't match those of the prior period/segments.

  In this case, the system sums deltas by payment key (that is, only deltas with the same payment keys are summed) before forwarding them to the appropriate slice or segment in the current period.

• A payee who was calculated as part of a calendar is later discovered to not belong in the calendar.

  In this case, the system reverses prior calculations for the payee. For example, this could occur in a retroactive transfer situation in which a payee is transferred in January, but the transfer is not recorded until February. The January period would need to be reversed entirely.

Following is an example of a related situation that requires a more selective reversal of prior results:

A retroactive calculation takes place on a calendar period that had adjustments for a payee's earnings pulled into it from previous periods (so that the payee received adjustments in addition to his or her current pay). Later, the payee must be reversed out of this calendar. In such a situation, you might need to preserve the adjustments that were forwarded to the calendar that is being reversed because those adjustments came from a calendar that is not being reversed. The system has been programmed to recognize situations like this and preserves the forwarded adjustments.