Understanding Positive Input

Instances

Positive input entries are also called instances. When entering positive input into the system manually, you assign an instance number to each entry. So, if a payee works overtime at three rates and you make three separate entries of positive input for the OVERTIME element, each entry has a different instance number. The following example assumes that the calculation rule is (Overtime) = (Rate) × (Units)

When positive input comes from external sources, the system assigns instance numbers. Whether the system assigns a separate instance number to each entry of positive input or to a group of entries depends on whether bundling occurred.

Bundling

Positive input created by the Absence Take process, Time and Labor, or a third-party application is often bundled by pay period into an array, for more-efficient processing. If a payee works eight hours a day on a weekly pay frequency, five eight-hour entries can be bundled into one 40 hour entry. Bundling has no impact on processing or results other than that it creates a single row of output (GP_RSLT_ERN_DED) instead of multiple rows.

Each bundle receives an instance number. Instance numbers begin with 1 and are assigned to each bundled element in a calendar run.

Rules for bundling data depend on the positive input source.

This diagram illustrates the sources of positive input and bundling.

Bundling Rules for Time and Labor

Positive input entries received from Time and Labor (called payable time in that application) are bundled by slice or segment when they contain compatible data—that is, when the values for the following types of data are identical:

• Rate.

• Currency.

• Rate as of date.

• Task entities*.

* To be considered for bundling, selected task entities defined in Time and Labor—including business unit, product, and department—must be mapped to system elements or variable elements in Global Payroll using the Mapping page.

Example 1

A payee has five positive input entries, one for each weekday. Each entry specifies a rate value as in the table. The rate earned every day except Thursday is the same. Therefore, the system bundles and creates one instance for the four days with a rate of 10 and creates a separate instance for Thursday, with a rate of 12:

Example 2

A payee performs work in two departments. The positive input entries include a system element that defines the department (A or B) and a variable element that specifies the hours worked. Because the system elements must match for bundling to occur, the system bundles all entries for department A and creates another bundle for the department B entries:

Bundling Rules for Absence Take

Positive input that's created by the Absence Take process and that falls in the same slice or segment can be bundled, depending on the take element definition:

• If you didn't select the Multiple Instances option for the take element, positive input for absences taken for the same reason during the pay period is bundled.

• If you allocated the positive input associated with an absence take element to more than one earning or deduction element (on the Absence Take - Day Formula page), the system bundles the positive input for each earning and deduction element separately.

Bundling Rules for Third-Party Applications

Positive input received from third-party applications can be bundled or unbundled, depending on the bundling group tag assigned to each instance before transmission to Global Payroll. The third-party application must use a unique value for the Source (PI_SOURCE) field and handle any segmentation requirements. It is the responsibility of the third-party interface to bundle entries as required by Global Payroll.

Why Positive Input Might Not Be Resolved

If you discover that some instances of positive input weren't resolved during processing, the most likely causes—besides the aforementioned eligibility issues—are that:

• The value of a component of the element's calculation rule is defined as requiring payee level input, but you didn't specify the component's value through positive input or a payee override.

  If you enter positive input without values for the components, the element is resolved using the element's definition and payee override, if any.

• You entered positive input after running the last iteration of the payroll processing calculate phase or after freezing calculations for payees.

Override

When you enter positive input with the action type of Override, you can enter an amount that overrides the calculation rule for the instance of the element or enter a value for components of the element's calculation rule: rate, unit, percent, or base. (If the calculation rule is defined as amount, you can enter only an amount.)

Suppose that you define an earning code as a flat amount of 100 EUR. You want to give the payee 90 EUR instead. You enter the amount of 90 EUR on the Positive Input page, specifying the action type as Override. The system overrides the definition amount of 100 EUR that is resolved, and the payee receives 90 EUR.

Add

When you enter positive input with the action type of Add, the system processes the normal resolution of the element based on the element definition or instructions entered on the Element Assignment By Payee page or the Payee Assignments by Element page, if any. In addition, it processes the element again based on the values that you enter in positive input, resulting in multiple occurrences.

Suppose that you define an earning code as a flat amount of 100 EUR. You want to give the payee an extra 50 EUR. From a data entry standpoint, the administrator enters the additional 50 EUR on the Positive Input page, specifying the action type as Add. The system processes the definition amount of 100 EUR and then resolves the additional amount of 50 EUR, so that the payee receives 150 EUR.

Do Not Process

When you enter positive input with the action type of Do Not Process, you prevent the system from processing this element for the payee when calculating the calendar. No result is written to the result table.

Do Not Process instructions apply to all instances of positive input for the element—manual or system-generated—in all segments and slices of the calendar, unless you enter an end date (on the Other Data page), which enables you to limit the instructions to instances that fall in the same slice or segment.

Suppose that instance 1 has an action type of Do Not Process, and that instance 2, for the same element, has an action type of Override. If you don't enter an end date for instance 1, the Do Not Process instructions apply to both instances and neither is processed.

Resolve to Zero

When you enter positive input with the action type of Resolve to Zero, the system resolves the instance of the earning or deduction with a value of 0.

Unlike Do Not Process , Resolve to Zero writes an amount of 0 to the results table, making a zero amount on the payslip possible. Also, Resolve to Zero instructions do not affect any other instances.

Rules for Mixed Action Types

The following rules apply when positive input occurs with mixed action types within a segment:

• Where positive input entries are a combination of Add and Override action types, the system does not resolve the element definition because of the presence of the override entry.

  Instead, the system processes all positive input entries with action types of Override and Add in this order (hierarchically): first the entry with an action type of Override, then the entry with an action type of Add.

  Suppose that E3 is a flat amount of 100 USD. You create two positive input entries, one (instance #1) with an Add action type for 30 USD and one (instance #2) with an Override action type for 200 USD.

  Despite the presence of what could be considered conflicting action types, the system processes both entries, regardless of the order in which you enter them. The system processes the entry with an action type of Override first and creates a row for 200 USD on the earning/deduction result table. Then the system processes the entry with an action type of Add and creates a row for 30 USD on the earning/deduction result table.

  The result is that the payee receives 230 USD for E3 with two rows on the earning/deduction result table. The system does not resolve the element based on its rule definition.

• Regardless of the combination of action types, the presence of an entry with an action type of Do Not Process always overrides any other positive input entries for that segment.

  In other words, the system processes nothing for the element. The Do Not Process value supersedes all action types.

• The action type Resolve to Zero affects only the current positive input instance.

  Where the action types of Override, Add, and Resolve to Zero are combined, the system processes all entries.

  Suppose that E4 is a flat amount of 500 USD. You create three positive input entries with the following attributes:

  • Action type of Override for 700 USD.

  • Action type of Resolve to Zero.

  • Action type of Add for 300 USD.

    The end result is that the system processes all three positive input entries and the payee receives 1000 USD for E4 with three rows (instances) in the earning/deduction result table. The system does not resolve the element through its definition. Also, the system creates a row with a result amount of 0.

Example 1: Effect of Period Segmentation on Positive Input

You're processing your January payroll. On January 16, a payee is promoted, causing period segmentation (two gross-to-net payments). In an unrelated transaction, You enter positive input for the payee's earning element with a begin date of January 20 and an end date of January 21. Because the end date for the positive input falls in segment 2, it's processed in segment 2 only. In segment 1, the earning element is processed as usual, unaffected by the positive input:

Example 2: Effect of Element Segmentation on Positive Input

You're processing your January payroll. On January 16, a payee's compensation rate changes, causing element segmentation (slices). Positive input is entered for the payee with a begin date of January 20 and an end date of January 21. Because the end date for the positive input falls in slice 2, the positive input is assigned to that slice. The element isn't processed in slice 1. In other words, the positive input overrides the element slicing. (The slice dates are still relevant to accumulators.)

Example 3: Effect of Element Segmentation on Payroll Calculations

Rules for assigning positive input to slices and segments can affect payroll calculations.

Assume that (GROSS) = (PAY1) + (PAY2) . Without positive input or segmentation, the elements' value is:

Tax = 390 [10% × 3900]

On June 10, the tax rate increases to 20 percent, triggering element segmentation. The segmentation event definition includes PAY1, PAY2, and TAX.

With element segmentation but no positive input, the value of each element is now as follows, assuming that PAY1 and PAY2 are prorated:

Tax = 650 [(10% × 1300) +(20% × 2600)]

Now suppose that you enter an instance of positive input, as follows:

Because positive input is assigned to a slice based on its end date and the end date of our instance falls in slice 1, positive input for PAY1 is resolved in slice 1 and overrides the element's standard calculation. In addition, PAY1 isn't resolved in slice 2, since positive input for an element overrides the regular resolution in all slices within the same segment.

With positive input and element segmentation, the elements' value is:

Tax = 480 [(10% × 3600) + (20% × 600)]

If the instance of positive input has the following begin and end dates instead, the input is assigned to slice 2, making the 3300 subject to 20 percent tax:

Then the elements' value is:

Tax = 810 [(10% × 300) + (20% × 3900)]

The tax amount is now 1080, not the 660 it would have been with the instance assigned to slice 1. The slice or segment to which positive input is assigned can significantly affect payroll calculations.

Unprocessed Positive Input

You can finalize a calendar run without processing all positive input. For example, if a payee has 10 units of positive input, and you change the units to 12 after running the Calculate phase, the system generates an iterative trigger (assuming that the units field is set up to generate iterative triggers). If you don't rerun the Calculate phase, only 10 units are processed. If you run a retroactive process, all 12 units are processed (assuming that the units field is also set up to generate a retroactive trigger).

Arrears - Payback

If positive input instances with the action type of Override exist, the system determines any arrears payback amount and adds it to the first positive input instance. If the element resolves multiple times per segment in the current period, the following hierarchy is observed when applying the Arrears - Payback amount:

1. Normal resolution of the element.

2. Override occurrence.

3. Additional occurrence.

When there are only Add type instances of positive input (and no other action types such as Override), the system applies the arrears payback to the initial calculation based on the normal resolution of the element and not to the subsequent additional resolutions of the element. If there is a mix of Override and Add action types, the system applies the arrears - payback amount to the override resolution of the element. Lastly, if a normal resolution of the element does not exist, and an override resolution of the element does not exist, then the system applies the arrears - payback to the additional resolution of the element. It is important to ensure that the system applies the arrears payback amount only once.

Frequency Conversion, Rounding, and Proration

The system does not apply frequency conversion, rounding, or proration to any numeric component or amount entered in positive input. For components not entered through positive input, normal rule processing occurs based on the element definition.

How the Batch Process Stores Positive Input

Manually entered positive input is maintained in a separate record from positive input that's automatically generated. However, all positive input considered during processing is stored in the same output record (GP_RSLT_PI_DATA), regardless of source. A second record (GP_RSLT_PI_SOVR) stores data for supporting elements, such as department or job codes that you entered manually or received from Time and Labor.

One row of data is written to the output table for each instance. Therefore, if entries are bundled, one row of data is written to the output table for the entire bundle. When a separate instance number is assigned to each entry, a row of data is written to the output table for each entry.

The instance numbers stored in the output table enable you to link each entry to the processing results. An automatically generated source code (PI_Source) identifies the origin of the entry: Absence, Generated PI, Manual, or Time & Labor.