Understanding Complex Retro Processing

Calculating Deltas in Matched and Mismatched Segments

The way that Global Payroll calculates deltas varies depending on whether the segmentation dates and payment keys of the prior period match those of the recalc period.

When Segments Match

When segment dates match and payment keys are the same, the system recalculates the original segments (to determine the new values for each segment), subtracts the old value from the new value for each element of pay (to determine the retro deltas), and writes new results to the output tables. (See Example 1: Retro With Matching Segments in this topic.)

When Segments Don't Match

When segments don't match, the system treats the old and new values as if they belong to separate segments.

• The system creates reversal segments for each segment that existed in the prior calculation and then creates new recalc segments.

• A reversal segment does not have any results because it does not go through gross-to-net processing. The only results that are written to the output result tables are for deltas and balance accumulators. When calculating deltas, the new values are assumed to be 0 (delta = new value [0] – old value).

The new recalc segments go through gross-to-net processing and generate the new values. The new values are written to the output result tables. When calculating deltas, the old values are assumed to be 0 (delta = new value – old value [0]).

See Understanding Segmentation Setup, Understanding the Organizational Structure.

Example 1: Retro with Matching Segments

When the segment dates of the recalc period match those of the original period, retro processing is straightforward, as shown in the following example of retro going back to a segmented period.

Scenario:

• The original January pay period is segmented due to a change in pay group that is effective on 16 January.

• The January pay period must be recalculated for retro due to a change in E1 from 300 to 600 that is effective on January 1.

Image: Retro with matching segments

This diagram shows an example of retro with matching segments.

When the January pay period is reprocessed, the original segmentation dates are preserved. To determine the deltas for these segments, the system first matches segment 1 to segment 1 and segment 2 to segment 2. Then it subtracts the old value of E1 for each segment from the new value (E1 is defined to be prorated). As with retro without segmentation, the system recalculates each segment in the period and writes new values for each segment to the output result tables.

See Tracking Recalculated Calendars.

Example 2: Retro with Mismatched Segments

When the segment dates of the recalc period don't match those of the prior period, the system calculates retro deltas as described earlier in Calculating Deltas in Matched and Mismatched Segments.

Image: Retro with mismatched segments

This is an example of retro going back to a segmented period. In this example, when the period is reprocessed during retro, the prior segmentation dates change.

Scenario:

• The original January pay period is segmented when a payee moves from company ABC to company DEF, effective January 11.

• The original pay period is recalculated when the effective date of the payee's company transfer changes from January 11 to January 16 (that is, the segmentation date changes from January 11 to January 16).

• The payee's earning (E1) are 620 and are defined to be prorated.

In this example, the original January pay period is segmented due to a change in company ID effective on the eleventh of the month. The January calendar is reopened for retro processing when the effective date of the company transfer changes from January 11 to January 16, which means that the segment dates for the original and recalculated periods do not match. When recalculating the calendar period for January, the system cannot match segment to segment as in the previous example—segments 1 and 2 no longer have exact counterparts in the recalculated period.

The values of segment 1 and 2 are reversed, resulting in negative deltas of - 200 and - 420 for segments 1 and 2, respectively. Then the system creates new recalc segments with unique, segmented status records in the recalc period—segments 3 and 4, whose deltas are 300 and 320. The system writes new values for each segment to the output result tables. For the reversal segments, only the balance accumulator and delta output result tables are updated.

Example 3: Mismatch in Changing Payment Key Values

The Global Payroll system also recognizes the following situation as a segment mismatch: when the value of a payment key (for example, company ID) changes between a prior calculation and the recalculation, Global Payroll treats the old and new calculations as belonging to separate segments—just as if the segment dates no longer matched.

See Payment Keys with Forwarding Retro.

Forwarding Adjustments in Retro with Segmentation

The way that Global Payroll forwards adjustments varies based on whether retro deltas are being forwarded to a sliced or segmented calendar and whether payment keys have been defined. Regardless of the situation, the system observes the following rules:

• As in retro without segmentation, the system uses retro matching criteria to determine whether it can forward deltas to a calendar in the current period. In other words, the system forwards deltas only when the employee ID, record number, pay entity, pay group, and run type of the source calendar match those of the target calendar in the current period.

  Note: You can override pay group matching by selecting the Deltas Cross Pay Groups option on the Retro Limits page. If you do this, the system automatically brings retro deltas into the current period even if the pay group associated with the deltas does not match the payee's current pay group. In addition, you can override run type matching by specifying additional valid run types in the Retro Adjustments Sources group box on the Run Types page. If you do this, the system automatically brings retro deltas into the current period for those additional types even though the deltas do not match the payee's current run type. However, all other matching criteria must still be met.

  See Retro Limits Page.

• If all retro matching criteria are satisfied, but the current period is segmented, the system sums and forwards deltas to the first segment in the current calendar.

  If that segment is sliced, the system forwards the adjustments to the first slice in that segment.

• If you have defined payment keys based on criteria such as company ID, contract number, establishment, or department ID, adjustments are forwarded only to the first segment in the current calendar that has the same payment keys as the forwarded adjustments (after all retro matching criteria have been satisfied).

  If that segment is sliced, the system forwards the adjustments to the first slice in that segment. If the system finds no segment with matching payment keys, it creates a new segment in the current period to which to forward the adjustments. The dates of the new segment are those of the calendar period as a whole, regardless of whether the current period is segmented.

See Payment Keys with Forwarding Retro.

Example 1: Element Segmentation with Retro

The following example of element segmentation with retro illustrates how the system forwards deltas to the current period (assume that all retro matching criteria have been satisfied and that there are no payment keys).

Scenario:

• Retro in period 3 back to period 1 due to a change in the value of E1 from 310 a month to 620 a month on January 16 (assume that E1 is defined to be prorated).

• E1 is on the element list for element segmentation and causes E1 to undergo segmentation into slice 1 and slice 2 in mid period—a period that was originally not segmented.

Image: Example of element segmentation in recalc period and no segmentation in current calendar

This diagram shows an example of element segmentation in the recalc period and no segmentation in the current calendar; there are no payment keys and retro match criteria are satisfied.

• Delta 155 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 1.

• Delta 310 is created in period 2; V1R2 is forwarded to period 3, V1R1, segment 1.

When the system calculates retro deltas for period 1, it subtracts the old value of E1 in period 1 (310) from the sum of E1 in slices 1 and 2 (155 + 320). Just as in retro without segmentation, the system forwards all deltas to the current period (March) using retro matching criteria.

Example 2: Period Segmentation Combined with Retro

The following example of retro with period segmentation illustrates how the system moves retro deltas from a segmented recalc period into a segmented current period, selecting the first slice/segment as the forwarding target using retro matching criteria.

Scenario:

• Retro in period 3 is back to period 1 due to a change in department ID (from department A to department B) on January 16, which triggered period segmentation in the January recalc calendar (assume that the original period was not segmented).

• The value of E1 increases from 310 a month to 620 a month in March, retroactive to January 1 (assume that E1 is defined to be prorated).

• On March 16, the department ID changes from department B to department C. This affects only the current period, resulting in a segmented current calendar.

Image: Example of period segmentation in recalc period and current calendar

This diagram below shows an example of period segmentation in both the recalc period and the current calendar; no payment keys are used and retro match criteria are satisfied.

• Delta 310 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 1.

• Delta 310 created in period 2; V1R2 is forwarded to period 3, V1R1, segment 1.

The system calculates retro deltas for January by summing the deltas for the reversal segment (segment 1) with segments 2 and 3. And when it calculates the deltas for February, it subtracts the value of E1 in V1R1 from E1 in V1R2. The system then pulls the deltas from the January and February recalc periods (310 + 310) into the first segment of the current calendar that satisfies retro matching criteria—that is, segment 1 in the March payroll calendar.

Example 3: Period Segmentation Combined with Retro—Payment Keys Used

The following scenario illustrates how the system handles retro deltas when retro matching criteria have been satisfied, a payment key has been defined (in addition to the standard retro matching criteria), but the payment key of the recalc period does not match that of the current calendar.

Scenario:

• The value of E1 increases from 310 a month to 620 a month in March, retroactive to January 1. This causes the January and February calendars to be recalculated.

• On March 1, the payee transfers from company ABC to company DEF. Company ID is defined as a payment key.

• On March 16, the department ID changes from department A to department B. This affects only the current period, resulting in a segmented current calendar.

Image: Example of company defined as a payment key (retro match criteria are satisfied)

This graphic is an example of a company defined as a payment key.

• Delta 310 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 3.

• Delta 310 is created in period 2; V1R2 is forwarded to period 3, V1R1, segment 3.

When the system first calculates the retro deltas for January and February, it tries to pull them into the first segment of the current calendar (March) based on retro matching criteria. However, these deltas were generated for a payee in company ABC, and the payee is now in company DEF (there was a company transfer on March 1). Because Company is defined as a payment key, the deltas cannot be forwarded to the first segment of the current calendar (March) even though all other retro matching criteria have been satisfied. Therefore, the system creates a separate segment with the same begin and end dates as the March pay period and moves the deltas into the new segment.

Payment Keys and Forwarding

When the payment keys of the current period do not match those of the period that is being recalculated, adjustments must be managed as a separate gross-to-net in the current calendar period. For example, Company has been defined as a payment key. A payee who is working in company ABC moves to company DEF in the current period. There is retro going back to a prior calendar when the payee was in company ABC, and there are adjustments to the payee's current period coming from the prior calendar. The adjustments are associated with company ABC, and the current period is associated with company DEF. In this situation, the adjustments are managed as a separate gross-to-net in the current period.

When deciding whether and where to forward adjustments, the system:

1. Determines whether retro matching criteria have been satisfied.

   If matching criteria have been satisfied, the system pulls retro deltas into the current period as adjustments.

2. Checks to see if you have defined payment keys based on criteria such as company ID, contract number, establishment, and department ID.

   If you have defined payment keys, the system checks those keys to determine where to forward the adjustments. If the value of the payment keys that are attached to the forwarded adjustments is the same as the value in the current period, the system forwards adjustments to the first segment in the current period that has matching payment keys. If that segment includes slices, the system forwards adjustments to the first slice in that segment.

3. Creates a new segment in the current period (when it finds no segment with matching payment keys) to which to forward the adjustments.

   The system manages the adjustments as a separate gross-to-net in the current period. The dates of the new segment are the dates of the calendar period as a whole, regardless of whether the current period is segmented.

   The new segment has the status Inactive in Segment and goes through the process list like any other gross-to-net calculation. Earnings and deductions are resolved again in this segment. The result may not be what you want for this type of segment. To prevent the earnings and deductions from being resolved again in this segment, the user can define a generation control element to exclude segments with the status Inactive in Segment.

   Positive input (PI) that is targeted to this calendar, as well as any generated PI topic, are not processed again in the Inactive in Segment segment, regardless of generation control.

See Understanding Calculation ElementsUnderstanding Processing Elements, Understanding Positive Input, .

Example 1: No Change in Payment Key Values

When the payment keys of the current period match those of the period that is being recalculated, the system forwards the adjustments to the current period. No new segments are created. Consider the following example of retro in February going back to January.

Scenario:

• Company ID is defined as a payment key.

• A payee's earning (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

Image: No change in payment key values

This graphic is an example of a payroll calculation in which there are no change to the payment key values.

Delta 400 is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 1.

See Tracking Recalculated Calendars.

Example 2: Payment Key Value Changes in Current Calendar Period

When payment keys in the current period do not match those in the period that is being recalculated, the system creates a new segment in the current period to which to forward the adjustments. Consider the following example of retro in February going back to January.

Scenario:

• Company ID is defined as a payment key.

• A payee's earning (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

• On February 1, the payee transfers from company ABC to company DEF.

Image: Payment key value changes

This graphic is an example of a payroll calculation in which the payment key value changes for the current calendar period.

Delta 400 is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 2.

Because the payee in this example moves from company ABC to company DEF in February, the payment keys in the current calendar (February) no longer match those in the calendar that is being recalculated (January). As a result, the system creates a new segment (segment 2) in February into which to pull the adjustments from period 1, V1R2. The begin and end dates of the new segment are identical to those in the current period (February 1 - 28).

See Tracking Recalculated Calendars.

Payment Keys and Retro Deltas

If the value of a defined payment key changes retroactively, so that a calendar that is associated with one set of payment keys must be reprocessed using payment keys with changed values, the system recognizes this condition as a segment mismatch. If a segment match on payment keys doesn't exist between the prior and the current periods, a new segment is created in the current period for the forwarded adjustment that results from the deltas that have old payment keys. This process is illustrated in the example below.

Scenario:

• A payee moves from company ABC to company DEF in February. The change is retroactive to January.

• Company ID is defined as a payment key.

• The payee's earning (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

Image: Payment keys and retro deltas

This graphic is an example of when a segment mismatch occurs during a payroll calculation.

• Delta <500> is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 2.

• The delta 900 created in period 1, V1R2 is forwarded to period 2, V1R1, segment 1.

When calculating the retro delta for E1 in January, the system cannot match the new value of E1 (900) to the old value of E1 (500) and compute the difference as it ordinarily would (900 - 500 = 400). The old and new versions of E1 belong to different segments, are linked to different payment keys, and are no longer treated as counterparts. To determine the deltas, the system must first reverse the old value of E1 in V1R1; that is, it treats the prior calculation of E1 in period 1 as having no corresponding value in the new segment and subtracts 500 from 0 to generate a negative - 500. Likewise, it sees the new calculation of E1 in period 1 as having no corresponding value in the old segment and subtracts 0 from 900 to generate a new value of 900 for E1.

Summing Deltas by Payment Key

The preceding example illustrates an important rule: when summing and forwarding deltas, the system sums only deltas with the same payment keys, and deltas that are associated with one set of payment keys cannot be forwarded to an element linked to different keys. In the preceding example, the delta (<500>) created in period 1, V1R2, is not added to the delta (900) created in period 1, V1R2, because the deltas are associated with different payment keys.

Example 1: Pay Group Transfer with Forwarding Retro

Scenario:

• In period 1, the payee is in pay group A. E1 = 100.

• In period 2, the payee transfers pay groups retroactively to pay group B, effective in period 1. E1= 200.

• The retro calculation involves retro in period 2 back to period 1.

• In period 1, V1R2, E1 is reversed completely. No new segment is created because the payee should not have a gross-to-net calculation during this period for pay group A.

• The E1 delta of <100> for period 1, V1R2 is not processed for the current calendar (period 2) because the payee is no longer in pay group A. If the current calendar is for pay group B, the delta is not pulled in as an adjustment until you manually redirect the unprocessed delta to a target calendar for pay group B.

Example 1: Retroactive Add with Forwarding Retro

Scenario:

• In period 2, information is received regarding a new payee that is hired in period 1.

• The first retro calculation involves retro in period 2 back to period 1.

• In period 1, V1R2 represents the retro processing for that period. The revision number is 2 even though Version 1 never existed, because the method is forwarding, and the recalculation does not represent the true results.

• The delta for period 1, V1R2 is pulled into period 2, V1R1 as an adjustment.