Académique Documents
Professionnel Documents
Culture Documents
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
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.
All Elements
There are two attributes on the Element Name page that can affect performance and data volume: Always Recalculate and Store/Dont Store.
Version 1.0
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.
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.
Version 1.0
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.
Examples:
Version 1.0
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.
Version 1.0
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
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
, 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
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
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
[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
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
[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
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
[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
Version 1.0
13
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
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
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
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.
Version 1.0
17
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
Version 1.0
18
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
Version 1.0
20
GP_PI_GEN_HDR * GP_PI_GEN_REF *
Version 1.0
21
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
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.
Version 1.0
23
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