Tuning PeopleSoft Global Payroll

Version 1.0

Table of Contents
Introduction.....................................................................................................................................1 Creating Performance Enhancing Rules.........................................................................................1 All Elements................................................................................................................................1 Arrays..........................................................................................................................................2 Brackets......................................................................................................................................8 Counts.........................................................................................................................................8 Formulas.....................................................................................................................................9 Generation Control Versus Conditional Section Logic..............................................................13 Historical Rules.........................................................................................................................14 Proration Rules/Counts.............................................................................................................15 Checking the Performance of Your Rules.................................................................................17 Methods for Reducing the Size of Result Tables..........................................................................17 All Elements..............................................................................................................................18 List of Tables to Aid in Archiving Solutions...................................................................................20 Tables to be Considered for Archiving......................................................................................20 Additional Archiving Tips...........................................................................................................23 Appendix A Special Notices.......................................................................................................23

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Introduction
This document is a practical guide for rule developers, technical users, installers, and programmers who implement, maintain, or develop rules for your PeopleSoft Global Payroll application. In this section we show you how to set up rules that improve performance, give you tips on reducing the volume of data stored on your tables, and make suggestions for archiving. Many of the ideas presented in this document originated from the PeopleSoft Development Center, so its based on development and experience. The information presented here are suggestions and not mandates for system setup. PeopleSoft updates this document so that it reflects feedback from the field. Therefore, the structure, headings, contents, and length of this document are likely to vary with each posted version. To see if the document has been updated since your last download, compare the date of your version to the date of the version posted on Customer Connection. This paper is not a general introduction to rule setup, these are instructions for enhancing performance. We assume that you are experienced in developing payroll rules and have a good understanding of PeopleSoft Global Payroll. To take full advantage of the information covered in this document, we recommend that you have a good understanding of Global Payroll, basic database concepts, SQL, and PeopleSoft applications. This text is not intended to replace the documentation delivered with the PeopleSoft HRMS 8, 8 SP1, or 8.3 PeopleBooks. We recommend that before you read this document, you read the Global Payroll related information in the HRMS PeopleBooks to ensure that you have a wellrounded understanding of our Payroll product.

Creating Performance Enhancing Rules

This section provides guidelines for developing rules that enhance performance. These guidelines include topics that apply to all elements and information specific to individual elements.

All Elements
There are two attributes on the Element Name page that can affect performance and data volume: Always Recalculate and Store/Dont Store.

The Always Recalculate Option

You should only select the Always Recalculate option (on the Element Name page, GP_PIN record) when it is required in situations where you encounter the element multiple times within the same slice or segment and you expect its resolved value to change. When the PIN manager encounters an element, it first checks to see if that element has already been resolved for the payee for the appropriate slice, segment, or period. If the element has not been resolved, the system automatically resolves the element, regardless of the Always Recalculate setting. If the element has been resolved, the system checks the Always Recalculate setting. If the setting is No, the system uses the previously resolved value. If the setting is Yes, the system resolves the element. Each resolution slows performance.

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

For example, assume that you are using the system element COMPANY as a user key in some of your accumulators and that you select Always Recalculate for the COMPANY system element. Each time an element is calculated and contributes to an accumulator, the process resolves the COMPANY system element. This can consume a lot of time and is not needed, as the company will not change within a specific slice or segment.

When to Store Data

We understand that from a testing perspective it is sometimes nice to store all elements in the results tables. You should not automatically do so. For testing purposes, remember that you can use the element resolution chain to assist with unit testing. There are two main reasons for not automatically storing all elements: Inserting data takes time. Adding data adds volume and slows SQL.

You should only be storing an element if it is needed in one of the following situations: Reporting, either in result tables or in a writeable array. Retroactivity. Historical rules. Fictitious calculations. Chartfields. Audits.

In addition, with earnings and deductions you have the ability to indicate whether you want to check the resolved value or all individual component values to determine whether to store the element. Unless you need the individual component values for purposes of reporting or historical rules, etc., you should only be storing earnings and deductions if the resolved value is not zero. See Methods for Reducing the Size of Result Tables, below, for more information.

Arrays
Arrays must be set up correctly in order to maximize performance.

Calling the Lookup Processing Option Formula

There are multiple ways to set up an array. The most important thing you can do to enhance performance is to reduce the number of times you call the lookup formula. If the goal of your array is to return only one row by segment or slice, it is best to avoid the lookup formula process by using the key page with the appropriate conditions and the return page with the appropriate logical order. Note. You should refer to PeopleBooks for information on how arrays work. To enhance performance, you must remember the main steps in array processing:

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

1. Load the data from the internal array using the where clause that you defined on the key page. 2. Read the rows from the internal array. Loading the data is done: By employee if you use tables keyed by employee. This is done across the entire run. Keep in mind the effect on retroactivity. By run if you use user-defined tables and do not specify the load field. By segment if you use user-defined tables and specify the load by segment. By slice if you use user-defined tables and specify the load by slice.

The rows are read whenever the array itself is encountered in the process as follows: 1. Select the first unread row in the internal array. 2. Read the row. 3. Populate the return element. Call the PIN Manager to update values in a specific array in memory. We call this array PINV. 4. Call the lookup processing option formula if applicable by calling the PIN Manager to resolve it. 5. The formula calls the programs it needs to resolve elements using the PIN Manager to call an appropriate program to resolve an element and update PINV. 6. If the formula is true, the array processing stops. Otherwise it returns to step two. Thus, if the array has 100 rows and the last row is the appropriate one for 90% of your employees, the process will execute steps two through six 100 times for each employee. This slows the system.

Ordering the Fields Retrieved

It is important to find the appropriate order of your rows to minimize the call to the formula. Usually, when you check an effective date it is better to order the date field by descending value. Effective date recommendations: Record name is keyed by employee, use Key Type of Keys page equal to Effdt. Record name is user-defined key. Do not use the Effdt field on the Keys page if you do not use the Array Loading field. In this case the array process only executes the where clause, including the control about the effective date, once. This means that the array process uses the first payee/segment information to execute the SQL statement. For the next payee/segments the array process only uses memory for the lookup formula. If you want to load all rows in memory and find the appropriate row, check the above example. Use Other Key Type on the Keys page and set the value to less than or equal to the appropriate Effective Date System Element, such as period, segment, or slice end date, if you are using reloading options.

Examples:

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

To illustrate the ways we can set up array elements and the impact each has on performance, we will take the COMPANY_TBL table as an example. Assume that the goal is to return the points value (stored in COMPANY_TBL.COMPANY_POINTS_VALUE field) for the COMPANY of the payee from the COMPANY_TBL During the test below, the company table had 178 rows of data, but the one we needed for our payee was the 86th row. Below are three ways to set up this array and the impact of each on performance. Note. This is an example for this specific situation. You must analyze all of your business requirements and determine the best approach for setting up the specific array. If you question the best option, run a few quick tests with the array set up different ways and determine which way is the best. See Checking the Performance of your Rules, below. Example One The array is set up loading all rows into memory. The lookup formula must find the correct row. In this example you would load all rows of the COMPANY table in memory and then execute the lookup formula to find the appropriate company row for each payee.

The returned fields are:

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

The lookup formula was executed 86 times for each segment. Note. The Effdt field must be arranged in descending order.

Example Two The array is set up to find the exact row. No lookup formulas are needed. This example illustrates a way to return only one row. If the SQL returns more than one, the first is the appropriate one.

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

As you can see, we reload the array for each payment. This means we execute the SQL by segment, not by run. The SQL returns the appropriate COMPANY with the appropriate effective date. Note. In the example above, we return the max effective dated row that is less than or equal to the Period End Date. You should determine which effective-dated row you need to read based on your own business requirements. The returned fields are:

As you can see, you need the effective date in descending order to make sure that the first row is the appropriate one. In this example, we do not need to execute a lookup formula. Example Three The array is set up using a view. You can retrieve the correct row without a lookup formula. To set this up you must first create a view and join COMPANY_TBL and JOB. SELECT A.EMPLID , A.EMPL_RCD , A.COMPANY

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

, A.EFFDT , B.COMP_POINTS_VALUE , B.CURRENCY_CD FROM PS_JOB A , PS_COMPANY_TBL B WHERE A.COMPANY = B.COMPANY AND A.EFFDT >= ( SELECT MAX(C.EFFDT) FROM PS_COMPANY_TBL C WHERE B.COMPANY = C.COMPANY ) You can now define an array keyed by employee. Because of that, you can use Effdt in Key Type. In this case the array process will read the Record Name as JOB record. This means it uses the Compare Effdt against system element to find the appropriate row as an As of Date.

There is no lookup formula. The results are: Array Array One User-defined No reload option Processing option formula 56 Number of Payees 5.09 Times

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Array Two User-defined Reload by segment No processing option formula required Array Three Payee level (using view) Key Type = Effdt No processing option formula required

56

0.91

56

1.76

Warning! This percentage can vary from one process to another. This is an example of the different ways that you can set up arrays. The main idea is that you should try to minimize the executions of the processing option formula.

Using the By Formula, Apply All Rows and the By Row, Apply All Formulas Options
You may use By Formula, Apply All Rows if you need a first reading before handing the array. Example: Perhaps you need to know if the age of each dependent is greater than the average age of all of an employees dependents. You must first read all dependents to calculate the average age. Then you must read each dependent to compare their ages with the average. Avoid this function. The process will redo steps one (Select the first row in the internal array), two (Read a row in the internal array), three (Populate return element), and four (Call the lookup processing option formula) for each formula. If you use the By Row, Apply all Formula function, the process does steps one through four for the first formula and the step four for subsequent formulas.

Brackets
We recommend that you not have more than 100 rows for the same effective date by bracket. If you have more than 100 rows for a bracket, you should consider using an array instead. See the Array section for more details.

Counts
See the Proration Rules section for more information.

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Formulas
Using Variables with Default Values
There are times that you will create a variable to hold a constant value, such as zero or one. An example of this is the GP TRUE and GP FALSE variables that are delivered as part of the GP Core Engine. Using these variables makes it easier to read some formulas instead of referring to numeric values. If a constant value changes over time and is used in several different rules, it may make sense to create a variable to hold this value. It is then easier to identify all of the elements that reference this variable and it is easy to change the value of the variable. There are also times when a constant value does not change over time or it is only referred to in one place. It might make more sense to just reference a number value directly in the element rather than create a variable to store that value. From a performance perspective, it is actually better to use a character, numeric, or calendar date value directly in a formula than to reference a variable. The process must resolve the variable, similar to an element. Note. The impact that this has on performance is not huge. You need to make sure that the setup does not impact long-term maintainability of your rules or complicate understanding. Example: (The words in brackets below reference an entry type.) Below are the results from sample performance tests that illustrate the concept above. Assume the we have one process list, one section, and two formulas in the section, as shown below: Formula FM1 [Numeric] 1 assign to [Variable] GP TEMP001 NUM (ten times)
[Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 0 >> [Formula] FM1

Formula FM2. GP TRUE does not use the Always Recalculate option because we want to compare PINV with a constant.
[Variable] GP TRUE assign to [Variable] GP TEMP001 NUM (ten times) [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM

Version 1.0

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

[Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Variable] GP TRUE >> [Variable] GP TEMP001 NUM [Numeric] 0 >> [Formula] FM2

The results are: Number of Payees Formula FM1, using Numeric 1 Formula FM2, using [Variable] GP TRUE Difference Percentage Difference 56 56 0.02 0.16 0.14 700.00 Time

Formulas that Use Other Formulas

It is common for some conditions or operations to be done multiple times to create a formula and then to call this formula (as a function) multiple times. It is impossible to say exactly when it is better to repeatedly call a formula versus rewriting the lines in a formula. The number of times you call the formula and the formula length play important roles. However, you should always think about this when making the decision on whether to create a separate formula. Maintenance is also a consideration. Example: Below are the results from some sample performance tests that illustrate this concept. Assume that we have one process list, one section, and three formulas in the section, as shown below: Formula FM1 [Numeric] 1 assign to [Variable] GP TEMP001 NUM (ten times)
[Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 1 >> [Variable] GP TEMP001 NUM [Numeric] 0 >> [Formula] FM1

Formula FM2 [Formula] FM3 assign to [Variable] GP TEMP001 NUM (ten times)
[Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM

Version 1.0

10

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

[Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Formula] FM3 >> [Variable] GP TEMP001 NUM [Numeric] 0 >> [Formula] FM2

Formula FM3. The Always Recalculate Indicator is not selected because we would like to compare PINV with a constant. [Numeric] 1 assign to [Formula] FM3

The results are: Number of Payees Formula FM1 does not use another formula Formula FM2 uses another formula Difference Percentage Difference 56 56 0.02 0.11 0.09 450.00 Time

Exit Functions
When you are using If logic in a formula, you should remember to use Exit logic whenever applicable so that the system does not resolve any unneeded elements. Example: Assume you have a formula as follows: IF Var 1 = 1 Else IF Var 1 = 2 Else IF Var 1 = 3 Else End if End if End if

Version 1.0

11

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

It would be better to replace the Else with an Exit statement. This way the system does not try to resolve the Variable Var 1 again in the second statement. If Var 1 = 1 Exit End if If Var 1 = 2 Exit End if If Var 1 = 3 Exit End if

IF Functions
When you have multiple conditions, you should always put the most popular condition at the top so that you match the majority of your population at the very beginning. Example: Assume your organization has two companies. Company XYZ has 10,000 payees. Company ABC has 1 payee. One of your formulas considers the company during calculation. It is better to start the formula by the largest company, XYZ, so your formula would be as follows: IF System Element / COMPANY Then Exit End If IF System Element / COMPANY Then End If = XYZ

= ABC

Min/Max Functions
When you need to retrieve the smaller or larger value of two or more elements, it is better to use the Min/Max function as opposed to If/Then logic. Example: Assume you need to compare the value of an employees year-to-date tax on a limit value, and you need to use the lesser of the two in a calculation. Formula FM1 uses If/Then logic (executed five times) If [Accumulator] YTD TAX > [Variable] TAX LIMIT Then [Variable] TAX LIMIT >> [Variable] GP TEMP001 NUM Endif

Version 1.0

12

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

[Numeric] 0 >> [Formula] FM1 Formula FM2 uses Minimum logic (executed five times) Minimum (Accumulator/YTD TAX & [Variable] TAX LIMIT) >> [Variable] GP TEMP001 NUM [Numeric] 0 >> [Formula] FM2 Number of Payees Formula FM1 uses If/Then, Endif logic Formula FM2 uses Minimum function logic Difference Percentage Difference 56 56 0.15 0.01 0.14 93 Time

Generation Control Versus Conditional Section Logic

As you know, generation control and conditional section logic are two of the various ways that you can control if an element is resolved for a payee. However, there is a big difference between generation control and conditional section logic. In fact, the conditional sections skip element resolutions. If you have Positive Input for an element in a section and the condition is false, the element will not be resolved, so the PI will be ignored. The same concept is true for the retro adjustments. Conversely, if you have a group of elements that you know should never be resolved except in a specific situation, such as a termination, it might make sense to use conditional section logic because it is easier and faster to bypass a subset of elements than to resolve generation control for each. If you are sure about your needs it is quicker to use a conditional section. But make sure that you understand the implications of conditional section logic before using it. Example: Assume you have an absence earning section for earnings/deductions generated by the absence process. All earnings/deductions use Payee Level for the unit. The earning/deduction is calculated if there is a PI. The process executes the earning/deduction module and checks if there is a PI. If there is not, the process skips this earning and goes to the next. You could consider using a conditional section to skip this section. In your day formulas for each absence take definition, you could populate one into a Unit component of a dummy element. To do this, use a Generated PI section with the dummy earning. If the employee does not have an absence, this dummy earning will not exist. If the employee is absent, the dummy earning will exist. In the payroll process, you can now put the dummy earning in a regular section to resolve it. Remember its a dummy earning so resolve it but make sure it does not add to your accumulators. Now you can check the value of this dummy earning in your conditional section logic to determine whether you need to resolve the absence earning section.

Version 1.0

13

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Historical Rules
There are times that you need access to data from previous periods in order to calculate an average or sum of values. As you know, one option is to create a historical rule to read all payroll results from one run and handle the sum and the average via formulas in historical rule. For example, if you need the average of the last 12 months of an element, read all of the segment stats. Select the data you need using the formula in the historical rule. This rule can cost time, as you would not want to execute this for a large percentage of your population. Before deciding whether to use a historical rule or not, you need to consider: 1. The number of periods or segments that your historical rule must read. 2. The frequency that your historical rule will be resolved. This will help you determine whether using a historical rule makes sense. Example: Assume you needed to calculate the average Salary (Base Salary + Overtime) of the last 12 months for a subset of payees. Below is an example of how this could be handled without using a historical rule in order to reduce the number of periods from which you need to retrieve data. Create two custom period accumulators. Use the system element HIRE DATE for the begin date option. The accumulator timing needs to be After Calculation. Accumulator One contains all of the elements you want to average in the member list. In our example this is Base Salary + Overtime. This accumulator tracks the total salary to date. Accumulator Two contains a variable element in a member list. The value of this variable should be equal to one. The purpose of this accumulator is to track the number of periods for which the payee received a salary. Note. You must ensure that the variable only resolves once per period. Pay attention to segmentation. Assume that we have the situation below: Period SALARY Value (Base Salary + Overtime) 10,000 11,000 11,000 11,000 11,000 12,000 12,000 13,000 Accumulator #1 (Sum of SALARY) 10,000 21,000 32,000 43,000 54,000 66,000 78,000 Not yet calculated so the value is 78,000 Accumulator #2 (Number of Periods) 1 2 3 4 5 6 7 Not yet calculated so the value is 7

Jan-2002 Feb-2002 Mar-2002 Apr-2002 May-2002 Jun-2002 Jul-2002 Aug-2002 (Current Period)

Version 1.0

14

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

In Aug-2002 you need to have the average of the six last months of the SALARY. You must have the sum from Feb-2002 to Jul-2002. To do this: Create a historical rule to read only one period before a specific date (one period before the earliest period you want to read). Create a Date Element to determine the date to read. In our example, we read the Jan-2002 period. You receive from the historical rule 10,000 for Accumulator One and one for Accumulator Two. Put these values into two variables. Now, the current value of Accumulator One is 78,000. Accumulator Two is 7. To find the actual information applicable to the last six months, take the difference between the current Accumulator One and the value retrieved for Accumulator One in the historical rule (which you have stored in a Variable) 78,000 10,000= 68,000. Divide this by the difference of Accumulator Two (7-1= 6). In this example you would have read only one row from the past, rather than seven. Remember though you always need to consider how often you will execute a historical rule, how many periods you need to read through, the impact to data volume, and your specific business requirements before deciding the best approach.

Proration Rules/Counts
If you must access Work Schedule information, such as scheduled hours, etc., in order to help resolve Proration Rules, you should try to read the work schedule only once in order to improve performance. You typically read a Work Schedule through a Count Element (which uses a formula that checks to see Scheduled Hours, etc.). When you need to have multiple proration rules such as calendar days, workdays and work hours for the same slice periods, it is better to have one count element to resolve all proration rules. Thus you read the work schedule information only once. Example: Assume you need to have a proration rule for the calendar days, work days and work hours. You would create the following elements: Three Proration Rules PRORAT_CAL_DAYS Numerator = Count/COUNT_NUM Denominator = Count/COUNT_DEN PRORAT_WRK_DAYS Numerator = [Variable] VAR_NUM_WRK_DAYS Denominator = [Variable] VAR_DEN_WRK_DAYS PRORAT_WRK_HRS Numerator = [Variable] VAR_NUM_WRK_HRS Denominator= [Variable] VAR_DEN_WRK_HRS Two Counts

Version 1.0

15

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

COUNT_NUM Formula = [Formula] FM_NUM

COUNT_DEN Formula = [Formula] FM_DEN

Four Variables VAR_NUM_WRK_DAYS, VAR_DEN_WRK_DAYS, VAR_NUM_WRK_HRS and VAR_DEN_WRK_HRS

Two Formulas FM_NUM /* To resolve the calendar days in numerator */ [Numeric] 1 assign to [Formula] FM_NUM /* To resolve the work hours in numerator */ [Variable] VAR_NUM_WRK_HRS + System Element SCHED HRS assign to Variable VAR_NUM_WRK_HRS /* To resolve the work days in numerator */ IF System Element SCHED_HRS <> 0 Then [Variable] VAR_NUM_WRK_DAYS + [Numeric] 1 assign to [Variable] VAR_NUM_WRK_DAYS End If FM_DEN /* To resolve the calendar days in denominator */ [Numeric] 1 assign to [Formula] FM_DEN /* To resolve work hours in denominator */ [Variable] VAR_DEN_WRK_HRS + System Element SCHED HRS assign to [Variable] VAR_DEN_WRK_HRS /* To resolve the work days in denominator */ IF System Element SCHED_HRS <> 0 Then [Variable] VAR_DEN_WRK_DAYS + [Numeric] 1 assign to [Variable] VAR_DEN_WRK_DAYS End If

In this example, you would need to make sure that Proration Rule PRORAT_CAL_DAYS is resolved first because it also resolves the numerators and denominators of the two other proration rules. If you need to have only calendar days, you could also just use two duration elements: one to calculate the number of days for the slice period (it uses the segment period if there are no slices), the other to calculate the number of days for the period.

Version 1.0

16

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Checking the Performance of Your Rules

To check the performance of your rules, you need to execute your calculation with the Trace All option selected on the Payroll/Absence Run Control. After that you can execute the SQL below to help analyze the performance of your rules. DECLARE @CAL_RUN_ID VARCHAR (18) SET @CAL_RUN_ID = 'KD%' SELECT A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_IND "Call From Process", COUNT(*) "Count Nb", SUM (A.DIFF_SECONDS) "Delay in Second", AVG (A.DIFF_SECONDS) "Average " FROM PS_GP_AUDIT_TBL A, PS_GP_PIN B WHERE A.CAL_RUN_ID Like @CAL_RUN_ID and A.PIN_NUM = B.PIN_NUM and A.DIFF_SECONDS > 0 GROUP BY A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_IND ORDER BY 1, 8 DESC

The Call From Process column indicates whether the element is called by a section. The time represented by the Delay in Second column is linked to the number of calls for this element (the Count Nb column). The Average column gives you the time to calculate an element. The result here is not to calculate the time to process, but to recognize what elements require the most time. Also you need to know that between two runs, without changes to process, your machine, or your environment, the response time could be different, especially with elements using SQL. This difference is because of how the database manager handles SQL scripts.

Methods for Reducing the Size of Result Tables

Data volume can impact performance and storage space. This chapter provides ideas on reducing the volume of data stored on the Global Payroll Result Tables. It includes general guidelines that apply to all elements and information for specific element types, such as earnings and deductions, accumulators, and supporting elements. We suggest that you consider all of these ideas while you create your rules in the implementation phase as they may impact other parts of your system, such as reports.

Version 1.0

17

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

All Elements
From a testing perspective it is sometimes nice to store all elements in the results tables, however, you should not automatically store these elements. Remember that you can use the Element Resolution Chain to assist with unit testing. There are two main reasons why you should not automatically store all elements: Inserting rows in results takes time. The larger the result table, the slower the SQL.

You should only be storing an element if it is needed in one of the following situations: Reporting, either in result tables or in a writeable array. Retroactivity. Historical rules. Fictitious calculations. Chartfields. Audits

Earnings and Deductions

Below are some specific rules to consider in relation to earnings and deductions: 1. Only store earnings and deductions if the result is not zero. Exceptions If Do Not Recalc on Retro is selected, the element should always be stored. In these situations you would need to know that the original value was zero and not recalculate it. If the element component value is needed for reporting and the result is zero, but the component is not zero. If the element is used in a Historical Rule, apply the following logic: - If you only need a value from the past, you do not need to store the element. The historical rule will return a zero value. - If you need to calculate an average based on the number of periods you may not need to store the element as you might be able to use another element to count the number of periods where this element is greater or less than zero. - If you need to calculate an average based on the number of times a payee should have this element, you must store it. 2. Do not store any dummy earnings or deductions that you use in the calculation. You can set the Store Indicator = N (via SQL) because there is no need to store in results tables. You should also remember to reset the Store if Zero indicator if applicable.

Version 1.0

18

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

Note. You must set the Store Indicator using SQL. The system prevents you making this change online as a precautionary effort.

Accumulators
Below are some specific rules to consider for accumulators: 1. Do not store Segment Period Accumulators unless they are needed for reporting, etc. Exceptions: You may want to store the value if the accumulator is used in a formula with the previous value turned on. This may be used for retro processing. You may want to store the value if the element is used in a Historical Rule. See the additional comments in the Earnings and Deductions section.

2. Do not store Balance Accumulators with zero values. Additional considerations are below. Custom Period Accumulator There is no automatic way to end a custom period accumulator. As a result, you should consider creating a formula to reset the value to zero when it is not needed. Maintain After End Date Logic Before electing to use Maintain After End Date logic, analyze how long you need access to this value and whether is would be better to use the Maintain After End Date logic or Historical Rules to retrieve applicable values. If you need access to this accumulator for a large subset of your population, using Maintain After End Date logic may make sense. However, if you only need to access this accumulator for a very small subset of your population, or in specific business scenarios, you may want to consider using historical rule logic instead. You should carefully analyze each individual case.

Supporting Elements
You should very rarely store supporting elements with zero values, unless they are needed for reports. When considering reports, you should also consider using a writeable array. Exceptions: The element is used as a Chartfield for General Ledger purposes. The element is used in a Historical Rule.

Example: The GP_RSLT_PIN record in HRMS 8.3 is uses 181 characters to store a result for a single element. If you use a writeable array, the record is approximately 82 characters plus the size of the column(s) in which you store your element values.

Version 1.0

19

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

List of Tables to Aid in Archiving Solutions

The goal of archiving is to reduce the data volume of some tables without having an impact on the payroll and absence procedures. The archiving has to be reversible; you must be able to restore the data you have archived back to the regular Global Payroll tables. Archiving result tables could be designed as a copy of the regular tables. Note. This chapter is not intended to provide exact guidance or methodology for archiving Global Payroll tables or restoring archived data. It is only intended to suggest some tables that you could archive, and provide some additional thoughts about how to approach the archiving of data.

Tables to be Considered for Archiving

Below is a list of Global Payroll Tables that you might want to consider archiving:

Global Payroll Result Tables

GP_RSLT_ABS GP_RSLT_ACUM GP_RSLT_DELTA GP_RSLT_ERN_DED GP_RSLT_PIN GP_RSLT_PI_DATA GP_RSLT_PI_SOVR GP_PYE_PRC_STAT * GP_PYE_SEG_STAT *

Global Payroll Result Tables - Writeable Arrays

All tables that are updated by Customer-specific Writeable Array Elements. Tables used in Global Payroll Country-Extension Writeable Arrays are highlighted in the Country-Specific tables section below.

Global Payroll Banking Result Tables

GP_PAYMENT

Global Payroll General Ledger Result Tables

GP_GL_DATA GP_ACC_LINE GP_ACC_LINE_STG

Global Payroll Positive Input 'input' Tables

GP_PI_MNL_DATA GP_PI_MNL_SOVR * GP_PI_GEN_DATA GP_PI_GEN_SOVR *

Version 1.0

20

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

GP_PI_GEN_HDR * GP_PI_GEN_REF *

Global Payroll Absence Event Entry 'input' Tables

GP_ABS_EVENT * These tables are not large, however, they are included because of their relation to the other tables noted above.

Global Payroll 8.3 Country Extension Specific Tables

Country Australia Table Name Used in Writeable Arrays: GPAU_PSLP_RSLT Additional Tables: GP_ABSEVT_SGPAU GPAU_ABSADV_CAL GPAU_ABSADV_SEG GPAU_ABSRET_CAL GPAU_ABS_RSLT GPAU_EE_FBT GPAU_EE_ETP GPAU_EE_PSM France Used in Writeable Arrays: GPFR_ASS_WA GPFR_DA_CONT_WA GPFR_DA_WA GPFR_DUCS_WA1 Germany Used in Writeable Arrays: GPDE_BV_RP GPDE_GR_RSLT_WA GPDE_RA_0001 GPDE_RP_0001 GPDE_RP_0002 GPDE_RP_0003 GPDE_RP_AZ01 GPDE_RP_FL01 GPDE_RP_SI01 Hong Kong Used in Writeable Arrays: GPHK_MPF_RSLT GPHK_PSLP_RSLT Italy Used in Writeable Arrays GPIT_ABS_INAIL GPIT_ABS_WKDATA GPIT_ABS_WKDATA

Version 1.0

21

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

GPIT_CUD_SPEPAY GPIT_CUD_WA GPIT_DM10_WA GPIT_F24_WA GPIT_PRS_WKDATA GPIT_RP_0001 GPIT_RP_0002 GPIT_RP_0003 GPIT_RP_0004 Japan Used in Writeable Arrays: GPJP_WA_PIN Additional Tables: GPJP_MTHRMN_LNG GPJP_MTHRMN_TBL GPJP_YEA_TABLE GPJP_YEA_HOUSE GPJP_YEA_LIFE GPJP_YEA_MUTAID GPJP_YEA_NONLIF GPJP_YEA_PENSN GPJP_YEA_SETUP GPJP_YEA_SOCINS GPJP_YEA_SPSDED GPJP_YEA_STATUS Mexico Used in Writeable Arrays: GPMX_ANL_ADJ_WA GPMX_FORM37_WA GPMX_LOAN_WA GPMX_SDIVAR_WA GPMX_SDI_WA GPMX_ST_TAX_WA GPMX_XMAS_WA Spain Used in Writeable Arrays: GPES_ADLN_RSLT GPES_SSTC_RSLT GPES_TAX_EE_DTA GPES_TAX_RSLT Switzerland Used in Writeable Arrays: GPCH_RP_0001 GPCH_RP_0002 GPCH_RP_EO01 GPCH_RP_FK01 GPCH_RP_FK02 GPCH_RP_MT GPCH_RP_PK01 GPCH_RP_SI07 GPCH_RP_SI08 GPCH_RP_TX01 GPCH_RP_TX02

Version 1.0

22

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

GPCH_RP_TX05 United Kingdom Used in Writeable Arrays: GPGB_EE_EXCEP GPGB_EE_RSLT

Additional Archiving Tips

Below are some additional thoughts that you might want to consider for archiving purposes. Warning! None of these methods are supported, maintained, or recommended by PeopleSoft. The preferred method is to archive entire sections of data using the tables above. However, below are some additional options.

Positive Input Generated by Absence Process

Tables concerned: PS_GP_PI_GEN_DATA, PS_GP_PI_GEN_SOVR As you know, the absence process generates PI day-by-day and take-by-take. After that the payroll process bundles the data with specific rules like group by rate, percent, and slice periods. The payroll process stores the result of the bundling in the PI result tables (PS_GP_RSLT_PI_DATA and PS_GP_RSLT_PI_SOVR). After this payroll run, the PI details can only be used for reporting or auditing. If you do not use these details, you can archive them.

Daily Absences
Table concerned: PS_GP_RSLT_ABS The system inserts one row for each daily absence in the absence result table (PS_GP_RSLT_ABS). A ten day absence generates ten rows in the absence result table. Sometimes a take element maps to another element when the balance is negative. For these days the absence results table has two rows. If you do not need the first take for a subsequent calculation, or for a future report, you can archive it.

Appendix A Special Notices

All material contained in this documentation is proprietary and confidential to PeopleSoft, Inc., is protected by copyright laws, and subject to the nondisclosure provisions of the applicable PeopleSoft agreement. No part of this documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, including, but not limited to, electronic, graphic, mechanical, photocopying, recording, or otherwise without the prior written permission of PeopleSoft, Inc. This documentation is subject to change without notice, and PeopleSoft, Inc. does not warrant that the material contained in this documentation is free of errors. Any errors found in this document should be reported to PeopleSoft, Inc. in writing.

Version 1.0

23

PeopleSoft Resume Processing Handbook

Release 8.01 and Release 8.3

The copyrighted software that accompanies this documentation is licensed for use only in strict accordance with the applicable license agreement, which should be read carefully as it governs the terms of use of the software and this documentation, including the disclosure thereof. See Customer Connection or PeopleBooks for more information about what publications are considered to be product documentation. PeopleSoft, the PeopleSoft logo, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, and Vantive are registered trademarks, and PeopleTalk and "People power the internet." are trademarks of PeopleSoft, Inc. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice. Information in this book was developed in conjunction with use of the product specified, and is limited in application to those specific hardware and software products and levels. PeopleSoft may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. The information contained in this document has not been submitted to any formal PeopleSoft test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by PeopleSoft for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites.

Version 1.0

24