Tuning People Soft Global Payroll

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......................................................................................................................... 13

Proration Rules/Counts.............................................................................................................15

Checking the Performance of Your Rules.................................................................................16

Methods for Reducing the Size of Result Tables..........................................................................17

All Elements.............................................................................................................................. 17

List of Tables to Aid in Archiving Solutions...................................................................................19

Tables to be Considered for Archiving......................................................................................19

Additional Archiving Tips...........................................................................................................22

Appendix A – Special Notices.......................................................................................................23

Version 1.0

PeopleSoft Resume Processing Handbook Release 8.01 and Release 8.3

IntroductionThis 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 it’s 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 well-rounded understanding of our Payroll product.

Creating Performance Enhancing RulesThis 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/Don’t 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 1


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 2


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 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 4


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 5


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 6


, 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 Number of Payees Times

Array One

User-defined

No reload option

Processing option formula

56 5.09

Version 1.0 7


Array Two

User-defined

Reload by segment

No processing option formula required

56 0.91

Array Three

Payee level (using view)

Key Type = Effdt

No processing option formula required

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 employee’s 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 8


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] 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





Version 1.0 9








The results are:

Number of Payees Time

Formula FM1, using Numeric 1

56 0.02

Formula FM2, using [Variable] GP TRUE

56 0.16

Difference 0.14

Percentage Difference 700.00

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)












Formula FM2

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

[Formula] FM3 >> [Variable] GP TEMP001 NUM



Version 1.0 10










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:


Formula FM1 does not use another formula

56 0.02

Formula FM2 uses another formula

56 0.11

Difference 0.09

Percentage Difference 450.00

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

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.

Version 1.0 11


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 = ‘XYZ’Then …ExitEnd IfIF System Element / COMPANY = ‘ABC”Then …End If

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 employee’s 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


Formula FM2 uses Minimum logic (executed five times)

Version 1.0 12


Minimum (Accumulator/YTD TAX & [Variable] TAX LIMIT) >> [Variable] GP TEMP001 NUM



Formula FM1 uses If/Then, Endif logic

56 0.15

Formula FM2 uses Minimum function logic

56 0.01

Difference 0.14

Percentage Difference 93

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 it’s 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.

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.

Version 1.0 13


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 payee’s. 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)

Accumulator #1 (Sum of SALARY)

Accumulator #2 (Number of Periods)

Jan-2002 10,000 10,000 1

Feb-2002 11,000 21,000 2

Mar-2002 11,000 32,000 3

Apr-2002 11,000 43,000 4

May-2002 11,000 54,000 5

Jun-2002 12,000 66,000 6

Jul-2002 12,000 78,000 7

Aug-2002 (Current Period)

13,000 Not yet calculated so the value is 78,000

Not yet calculated so the value is 7

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.

Version 1.0 14


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

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

Version 1.0 15


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.

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

Version 1.0 16


WHERE A.CAL_RUN_ID Like @CAL_RUN_ID and A.PIN_NUM = B.PIN_NUMand A.DIFF_SECONDS > 0GROUP BY A.CAL_RUN_ID, B.PIN_NM, B.PIN_TYPE, B.RECALC_IND, A.SUM_INSTANCE_INDORDER 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 TablesData 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.

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.

Version 1.0 17


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.

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.

Version 1.0 18


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.

List of Tables to Aid in Archiving SolutionsThe 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:

Version 1.0 19


Global Payroll Result Tables

GP_RSLT_ABSGP_RSLT_ACUMGP_RSLT_DELTAGP_RSLT_ERN_DEDGP_RSLT_PINGP_RSLT_PI_DATAGP_RSLT_PI_SOVRGP_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_DATAGP_ACC_LINEGP_ACC_LINE_STG

Global Payroll Positive Input 'input' Tables

GP_PI_MNL_DATAGP_PI_MNL_SOVR *GP_PI_GEN_DATAGP_PI_GEN_SOVR * 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 Table Name

Australia Used in Writeable Arrays:

GPAU_PSLP_RSLT

Additional Tables:

GP_ABSEVT_SGPAUGPAU_ABSADV_CAL

Version 1.0 20


GPAU_ABSADV_SEGGPAU_ABSRET_CALGPAU_ABS_RSLTGPAU_EE_FBTGPAU_EE_ETPGPAU_EE_PSM

France Used in Writeable Arrays:

GPFR_ASS_WAGPFR_DA_CONT_WAGPFR_DA_WAGPFR_DUCS_WA1

Germany Used in Writeable Arrays:

GPDE_BV_RPGPDE_GR_RSLT_WAGPDE_RA_0001GPDE_RP_0001GPDE_RP_0002GPDE_RP_0003GPDE_RP_AZ01GPDE_RP_FL01GPDE_RP_SI01

Hong Kong Used in Writeable Arrays:

GPHK_MPF_RSLTGPHK_PSLP_RSLT

Italy Used in Writeable Arrays

GPIT_ABS_INAILGPIT_ABS_WKDATAGPIT_ABS_WKDATAGPIT_CUD_SPEPAYGPIT_CUD_WAGPIT_DM10_WAGPIT_F24_WAGPIT_PRS_WKDATAGPIT_RP_0001GPIT_RP_0002GPIT_RP_0003GPIT_RP_0004

Japan Used in Writeable Arrays:

GPJP_WA_PIN

Additional Tables:

GPJP_MTHRMN_LNGGPJP_MTHRMN_TBLGPJP_YEA_TABLEGPJP_YEA_HOUSEGPJP_YEA_LIFEGPJP_YEA_MUTAIDGPJP_YEA_NONLIF

Version 1.0 21


GPJP_YEA_PENSNGPJP_YEA_SETUPGPJP_YEA_SOCINSGPJP_YEA_SPSDEDGPJP_YEA_STATUS

Mexico Used in Writeable Arrays:

GPMX_ANL_ADJ_WAGPMX_FORM37_WAGPMX_LOAN_WAGPMX_SDIVAR_WAGPMX_SDI_WAGPMX_ST_TAX_WAGPMX_XMAS_WA

Spain Used in Writeable Arrays:

GPES_ADLN_RSLTGPES_SSTC_RSLTGPES_TAX_EE_DTAGPES_TAX_RSLT

Switzerland Used in Writeable Arrays:

GPCH_RP_0001GPCH_RP_0002GPCH_RP_EO01GPCH_RP_FK01GPCH_RP_FK02GPCH_RP_MTGPCH_RP_PK01GPCH_RP_SI07GPCH_RP_SI08GPCH_RP_TX01GPCH_RP_TX02GPCH_RP_TX05

United Kingdom Used in Writeable Arrays:

GPGB_EE_EXCEPGPGB_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

Version 1.0 22


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 NoticesAll 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.

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.

Version 1.0 23


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

Date post:	28-Nov-2014
Category:	Documents
Upload:	jreddyus
View:	495 times
Download:	14 times

Tuning People Soft Global Payroll

Documents