Understanding Data Retrieval Elements

System elements are delivered and maintained by PeopleSoft, and contain information that you can use to define your payroll rules. You never have to change system elements or do anything special to define them. You cannot add system elements; however, you can rename them.

There are two types of system elements:

• Database system elements

  Think of database system elements as payee-related elements. They contain data that can be used frequently in a calculation, such as department ID, location, and personal data. Database system elements are resolved only when they are used in a calculation.

• System-computed elements

  System-computed elements are populated by the payroll process, but are not physical database fields. If, when, and how often a system-computed element is resolved depends on its purpose and type.

  For example, Pay Period End Date and Period Type are resolved at the beginning of every gross-to-net calculation; daily data, which is used in absence calculations, is calculated daily. Other system-computed elements, such as those that are used with rate codes, are resolved only when a rate code element is encountered in a calculation.

An array is a link between a field and an element. An array retrieves data that's stored in the database tables that Global Payroll does not provide in system elements. You can use arrays to retrieve complex data that's stored in any table outside Global Payroll. For example, you can create an array to retrieve birthday data for a payee's dependents from the DEPENDENT_BENEF table in PeopleSoft HR.

Arrays are temporary tables that the COBOL programs use to store the data during processing. Once processing is complete, the programs write the data from the temporary arrays to the output tables.

Using an array is a two-step process:

1. Retrieve data from the database.

2. Use that data for further processing.

When defining an array, you must provide enough information to the system so that it can perform both steps.

A writable array writes the values of user-defined elements into a row in a table. Writable arrays are in many ways the opposite of standard arrays.

You can use writable arrays to populate your own result tables. You use PeopleSoft Application Designer to create the result table, and then you use the writable array pages in Global Payroll to define the element that populates the table during batch processing.

Use brackets to look up and retrieve values in a lookup table based on other values.

For example, say that your organization gives bonuses based on seniority. You build a bracket that lets you look up the correct bonus amount based on a payee's years of service.

Use rate codes to resolve multiple components of pay, including base pay and non base pay. Rate codes retrieve multiple components of pay data from HR and bring that data into Global Payroll. The system calculates the values in Global Payroll, rather than transferring the data directly from HR so that currency conversions can be calculated for each payroll run.

HR rate codes (HR rate codes) are not automatically resolved in Global Payroll. To pay the rate code, you set up an earning element in Global Payroll and use the rate code element within the definition of that earning. You must define an earning element for every rate code element that you want to pay.

Define fictitious calculation rules when you want the system to perform a temporary calculation and return a value without having to store it. A fictitious calculation is a sub-calculation that is run during a normal calculation to determine a net that would be computed if certain parameters were used. This result is used for further processing in the normal calculation. A fictitious calculation always starts from inside a normal calculation and is run for one payee and for a specified set of periods. The intermediate results of a fictitious calculation are not needed and are ignored, except for the small subset of results brought forward to the normal calculation.

One example of using a fictitious calculation is maternity leave. Let's say that you provide payees with three months of pay for maternity based on the average net of the three months preceding the leave. The average net is calculated only when a certain condition (in this case, maternity) is met. As long as the payee is on maternity leave, the average is needed. If certain values change, the average must be recalculated for the original three periods, even if the change in values is effective-dated for a later date.

You use historical rule elements to set up rules that retrieve data from prior periods. You can use historical rules in formulas and in fictitious calculations.

An example of using historical rules is when you want to create a rolling average three-month salary. Let's say that you are currently in the April pay period (end of month). You can define a historical rule to go back three months, to the beginning of January, to average a payee's salary. As you move into the May pay period, the three months roll forward so that the calculation of the average is always based on the last three months.

A historical rule can be:

• Attached to an earning or deduction element on the Definition page.

• Attached to any element that's stored in the Global Payroll Earnings/Deductions results table, the Global Payroll Accumulator results table, or the Global Payroll Element results table.

• Used by fictitious calculation elements to find periods to recalculate.