This chapter provides an overview of the Absence Management utilities and discusses how to:
Define element relationships.
Add records to an element map.
View element relationships.
Create and export rule packages.
View the status of packages.
Compare and upgrade rule packages.
Rename elements.
Create and export non-rule packages.
Compare and upgrade non-rule packages.
Copy packages.
Stamp and package elements by version.
This section discusses:
Utility usage guidelines.
The packaging and upgrading processes.
Base and related languages.
The versioning functions.
The delete functions.
The process of connecting UNIX and NT directories.
Depicts the relationships between the elements in your database. The element map plays a critical role in packaging and moving elements and data to other databases. Because the map must be current and accurate when you create packages, the system rebuilds it when you start the process that creates rule packages. During mapping, the system validates that the defined fields exist in the records. Note. Mapping includes PIN-level records only. You must include those records that don’t have a PIN number as the primary key in order to use the non-rule packager. |
|
Focus Element |
The focal point of a process or action. |
Non-rule |
Non-rule data includes processing results, payee data, setup definitions, and other data where PIN_NUM isn’t the primary key. |
Package Status |
Click this link to access the Package Status page. |
The only element attribute that must be unique across databases. Like a PIN number, it’s automatically assigned to every element, those delivered by PeopleSoft and those you create. The Code consists of the element name plus the suffix ALL if the element is used by all countries, or a three-character country code if the element is used by one country—for example, BASE ALL or BASE ITA. When you move elements between databases, the system compares the elements that you’re exporting with those in the target database. PIN code is one of the attributes that the system checks when comparing elements. |
|
This number is a pointer back to a PIN name-related data in GP_PIN, and other tables. It is generated and assigned to every element, those delivered by PeopleSoft and those you create. Absence Management programs access and process elements by referring to their PIN numbers (PIN_NUM), not their names. PIN numbers are assigned sequentially in a given database, meaning that the same element can have different PIN numbers in different databases. So when you move elements between databases, the utilities don’t rely on the PIN number to determine if the source elements that you’re copying exist in the target database. |
|
Rule |
In Absence Management a rule is an element or combination of elements used to define a business rule. For example, an entitlement or take rule, or a count or rounding rule. The primary key for rule-definition tables is PIN_NUM. |
Target PIN Number (target pay item name number) |
The element's PIN number in the target database. |
Upgrading |
This process consists of copying items from a source database to a target database; comparing the copied items with items already in the target database; overlaying items in the target database or adding new items, depending on the comparison results; and deleting selected items from the target database. |
Source Database |
The database containing the rule or non-rule elements that you are packaging from and moving into the target database. |
Target Database |
The database into which you are moving the packaged rule or non-rule elements from the source database. |
See Also
Why the Core Application Uses Element Name Number (PIN) Processing
Absence Management provides a suite of integrated tools for implementing and maintaining the elements that define your absence rules. You can use these utilities to view the relationships between elements, package and move elements and data between databases, and delete elements. When implementing your absence system, you can use the utilities to move all or selected rules that you’ve created and tested into your production database. In an existing system, these utilities streamline the process of introducing new rules, installing system updates, and moving processing results and absence data to other databases.
Here are some guidelines for using the utilities:
Operations involving the utilities can have a significant impact on the system, so anyone using these tools must be very familiar with Absence Management.
Source and target databases must use the same PeopleTools release.
The source and target databases used by the non-rule packager must share the same base language.
Do not change the PIN_CODE in the Absence Management language table (GP_PIN_LANG).
Doing so can affect your ability to move elements.
The utilities shouldn’t be used during an absence run or while online work is being performed, but rather after business hours.
You can import only one package at a time.
Warning! Attempting to import more than one package at a time could result in the loss of critical data.
To move rules and data between databases, you use several utilities in a specific sequence. This illustration shows the typical sequence for using the utilities to move rules and data between databases:
Moving rules and data between databases
To move rules and data between databases:
Create and upgrade a rule package.
A rule package contains elements that are defined in records with PIN_NUM as the primary key. You use the Create/Export Rule Package and Apply Rule Package components to package and upgrade the elements you want to move. You can select individual elements for a package by name or by attribute, or you can select elements based on their version number. You tell the system whether you want to include only the focus elements or the focus elements plus the elements the focus elements use, based on the element map.
You can direct the system to delete or upgrade elements in the target database. A batch process creates a package of elements that you can view online.
After creating a package, you export it from the source database and import it into the target database; the system adds 50 000 000 to the value of each PIN number in the package to avoid overwriting elements in the target database that have matching PIN numbers.
An batch compare process follows, in which the system compares the packaged elements with those in the target database. The goal is to determine which elements are new to the target database, which match elements that exist in the database, and which need deleting according to your instructions. Elements that are new to the target database are assigned the next PIN number.
After reviewing the results of the comparison and resolving conflicts, you complete the upgrade process.
Create and upgrade a non-rule package.
Non-rule packages contain data from records where PIN_NUM is not the primary key—plus information about related elements.
To create a non-rule package:
Define the criteria for creating the package of data to move.
Export the non-rule data and element information from the source database.
Import information for the elements (not the elements themselves) into the target database.
Run a compare process that compares the packaged elements with those in the target database and identifies conflicts to address before importing non-rule data.
Import the non-rule data and start an upgrade process that renumbers the PINs in the non-rule data records that were moved to the target database.
For example, imagine that the absence results record (GP RSLT ABS) contains a take element with a PIN number of 1333 on the source database. The element was moved to the target database, and because it matches (based on PIN code) an element in the target database with PIN number 3453, the non-rule packager renumbers the PIN number in the absence results record.
In the case of rule packages, the source and target database need not have the same base language. The rule packager, using Data Mover functionality, can identify the base language in the target database and use the correct language from either the base or related language table if that language existed in the source package. Additionally, the rule packager also creates a related language entry on the target database for the source database's base language. Consider the following example:
A German (DEU) target database contains the following data:
Base Data
PIN_NUM |
PIN_CODE |
Translatable Data |
Non translatable Data |
701 |
GP_TEMP001_DEU |
Current German Text content |
Current values on the target database |
You create a package from an English (ENG) source database copying PIN_CODE GP_TEMP001 for base language only. The system:
Exports a data file containing information for PIN_CODE GP_TEMP001 from the ENG database.
The data file contains the new PIN_NUM of 50 000 701.
Imports the data file to the target database.
Upon import, DataMover automatically creates a related language row with a language code of ENG.
The German target database now looks like this:
PIN_NUM |
PIN_CODE |
Translatable Data |
Non translatable Data |
701 |
GP_TEMP001_DEU |
CONTENT |
Current values on the target database |
50 000 701 |
GP_TEMP001_DEU |
TAKE |
New values from the source database |
Related Language Data
PIN_NUM |
PIN_CODE |
LANGUAGE_CD |
Translatable Data |
50 000 701 |
GP_TEMP001_DEU |
ENG |
TAKE |
The system then:
Connects 50 000 701 with 701 using the PIN_CODE.
Copies the DEU translatable fields from 701 to 50 000 701.
Deletes the original PIN_NUM 701.
Renumbers the new rows with the PIN_NUM of the target database.
The result of the process is updated information on the base table and a new ENG entry on the related language table, as shown below.
Base Table
PIN_NUM |
PIN_CODE |
Translatable Data |
Non translatable Data |
701 |
GP_TEMP001 DEU |
CONTENT |
New values from the source database |
Related Language Table
PIN_NUM |
PIN_CODE |
LANGUAGE_CD |
Translatable Data |
701 |
GP_TEMP001 DEU |
ENG |
TAKE |
Had the package been defined as both base and related languages, the swapping of languages to some extent would already have been completed by datamover during the package import (if a related language row for the language of the target database was part of the package.) This would result in overlaying translatable fields of the base row with the contents of the copied language row. If only the related language was copied with the package, the process is the same as described above, except for translatable fields of the base row of the target database, which would be updated to contain the values of the moved language row.
You can use the versioning utilities of Absence Management to assign a version number to elements, and then have the system package only elements with this version number. Having created a package by version, you can move it to another database. In this case, the system moves changes from element definitions or component records.
Version-based packages only pull data from the database base language table, not from the Pay Item Names — Related Language table (GP_PIN_LANG). The only way to move related language information from GP_PIN_LANG is to use a regular rule package.
To delete rules from the target or source database, you can enter instructions for deleting elements when defining the selection criteria for a package. To preserve the integrity of your data, you can delete an element only if it’s not associated with other data. That is, the element being deleted must meet all the following conditions:
Not used in a result table.
Not associated with payee data.
Not linked to a non-rule table.
Not used by another element.
Not created by the PeopleSoft system.
Important! PeopleSoft recommends that you place elements to be deleted in a separate package from elements that you want to move from the source to the target database.
See Also
Selecting Elements for a Rule Package by Attribute
If your application runs on UNIX, exporting and importing packages involves additional considerations. You can create data mover scripts on the UNIX machine, but the data mover used for importing and exporting packages can only be run through an NT Process Scheduler.
Important! Any job or process that uses data mover in a UNIX environment must run on an NT Process Scheduler.
Because UNIX and NT reference directories differently, you must define a shared directory that can be accessed by both platforms. In order to do so, the same paths must be mounted on both platforms. The path name must be defined identically on both machines. For example, we have defined the following directory structure to store datamover files:
NT system: \\xx-xxx\hcm\datamover\
UNIX system: /xx-xxx/hcm/datamover/
When you specify the path names before creating scripts, importing packages, or exporting packages, you must always use the NT notation including the double back slash. PeopleCode automatically transcribes the path name to the appropriate platform notation when needed.
Important! You must add the location of your scripts to the psprcs.cfg file in the NT Process Scheduler. You should verify that the section marked [Data Mover] has the Input and Output paths pointed to the same drive.
To define element relationships, use the Define Element Relationships (GP_PIN_FLD_MAP1) component.
The Define Element Relationships utility builds an element map that shows how elements with PIN numbers are related. It defines the relationship between elements, and enables packager to determine if elements are used in non-rule data, which is important when deleting elements and packaging non-rule data.
Although the packager process rebuilds the map when you create a rule package, we recommend that you rebuild the map when you define new elements, change existing elements, or delete elements. It’s also advisable to rebuild the map for the target database after completing an upgrade. This ensures that the map is current when displayed.
This section discusses how to:
Rebuild element maps
Review for errors
See Also
Adding Records to an Element Map
Page Name |
Object Name |
Navigation |
Usage |
GP_PIN_FLD_MAP |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Define Element Relationships, Define/Build |
Start the GP_PINMAP process, which rebuilds element maps. View which records contain fields that store PIN numbers. You can add and delete records that you’ve created to the rule map. |
|
GP_PIN_FLD_MAP_ERR |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Define Element Relationships, Validation |
Review for errors after rebuilding the element map. |
Access the Define/Build page.
This page only lists those records that contain elements (which store PIN numbers). PIN NUM is often the key to these records, though this is not always the case.
Note. You cannot edit this page if it displays information for a PeopleSoft-delivered object.
See Adding Records to an Element Map.
Record Type |
Select a record type, which is the type of record that contains elements. Values are: Element Definition: Records of this type define elements with a primary key of PIN_NUM. Examples: GP_ABS_TAKE (absence takes), GP_ARRAY arrays and GP_FORMULA (formulas). Note. The Element Definition record type is used only by PeopleSoft. Records that contain elements but don’t define elements have one of the following record types: Set-up Definition: These are records you define when you implement Absence Management. Examples: GP_ELIG_GRP_MBR (eligibility group member) and GP_RUN_TYPE_DTL (run type detail). Output Result Data: These records contain calculation results. Examples: GP_RSLT_ACUM (accumulator results) and GP_RSLT_PIN. Payee Data: These records contain payee-specific data. Examples: GP_ABS_EVENT (absence events) or GP_PYE_OVRD (payee overrides). |
Record |
Displays the name of the record, containing one or more elements. |
Export Record |
Displays the name of the record that the system uses when exporting this data to another database. |
Effective Date Type |
Identifies whether the record is effective-dated. If this field is set incorrectly, the packager may fail. Effdt (effective date): This is the default value. Indicates that the record is effective-dated. Example: GP_BRACKET. Note. If you include in a package an element that has more than one effective-dated row, the system tries to match each row when comparing the source elements with the target database. If it finds a match, it replaces the row in the target database; if it doesn’t find a match, it adds the row to the target database. And if a row in the target database has no match, the system leaves the row in the target database unchanged. No Effdt (not effective-dated): Indicates that the record doesn’t have an effective date. Example: GP_ARRAY. Note. If you include in a package an element with no effective date, the system replaces all data for that element in the target database when you upgrade the package. Begin − End: Indicates that the record isn’t effective-dated but contains begin and end dates. Example: GP_ACM_MBR. Note. If you include in a package an element with begin and end dates, the system replaces all data for that element in the target database when you upgrade the package. |
Field Name |
Displays the name of the field in the record that contains other PIN number elements. For a record type of Element Definition, the system displays the name of the key field (PIN_NUM). |
Fields Referencing Other Elements
This group box displays all fields that store the PIN numbers of (member) elements that are used by the record/field combination at the top of the page.
The sample page displays information for GP_ERN_DED, the record that defines earning and deduction elements. This record can use up to 17 elements. PIN_AMT_NUM and PIN_BASE_NUM are some of the fields that store PIN numbers of member elements. For example, PIN_BASE_NUM identifies the element that returns the base amount. To resolve an earning or deduction element, the system must know the PIN numbers of elements that store the amount, base, generation control instructions, and so on.
Field Name |
Displays the name of the field that stores a member element’s PIN number. |
Field Long Name |
Displays the long name of the field. |
Field Status |
Displays the field’s status. Values are: Valid: Indicates that the field in the record existed when the element map was last rebuilt. Invalid: Indicates that a field has been renamed or removed from the record, or that the record no longer exists. The system flags invalid fields when you rebuild the element map. |
Applicable Element Types
When the record type is Element Definition, this group box identifies the corresponding element types.
Element Type |
Important when packaging elements. The element type that you select when creating a package gives the system information needed to select rows from the appropriate record. |
Rebuild Effdt Element Map (rebuild effective-dated element map) |
Click to start the rebuild process. If the system cannot build the element map because of errors, this message appears on the page: “Effdt Element Map hasn’t been built. Please check Validation page for errors.” Note. If the rebuild process is unsuccessful, an error message also appears in the message log. |
Access the Validation page.
Review this page for errors generated by the rebuild process.
Status |
Displays Invalid if an error occurred. Usually means that a field has been renamed or removed from the record, or that the record no longer exists. If this is a PS Delivered/Maintained (PeopleSoft system delivered/maintained) record, contact the PeopleSoft support. If the error involves a record that you created, check the record to make sure all the fields are still valid. |
Record (Table) Name |
Identifies the record that contained the invalid field. |
PIN Num Fieldname (pay item name number field name) |
Displays the name of the field that appears in the Field Name field at the top of the Define/Build page. |
Field Name |
Displays the field name that no longer exists in the record but appears on the Define/Build page. |
Message |
Displays an error message pertaining to the specific field. |
The procedure of adding records to an element map depends on the record’s main (first) key:
If the main key is PIN_NUM, the record type is Element Definition, (also called Rule Definition).
Note. Rule definitions are created only by PeopleSoft.
If the main key is not PIN_NUM, the record type is Output Result Data, Payee Data, or Set Up Definition, depending on its purpose.
This section discusses how to add non-rules to an element map.
This section describes the procedure for adding non-rule definitions to an element map, where the record’s main key is not PIN_NUM.
To add a non-rule to an element map:
Use PeopleTools to create a SQL view for the record.
The view must have the same structure as your new record, as illustrated in the following example.
In the Select statement, enter + 50 000 000 after each field in the record that references a PIN number.
On the Define/Build page, add a row for the new record.
Complete these fields on the Define/Build page:
For Record Type, select Output Result Data, Payee Data, or Set up Definition.
For Record, select your new record.
For Export Record, select the view that you created in step 1.
For Effective Date Type, select the appropriate value for the record.
For Field Name, select any field in the record that references PIN_NUM.
In the Fields Referencing Other Elements group box, list each field within your record that contains a PIN number.
This includes the field name defined in step e. You can select only PIN_NUM.
Example
This illustration shows how your SQL statement should match the record structure:
Record definition for GP_PYE_OVR_SOVR
SELECT EMPLID ,EMPL_RCD ,PIN_NUM + 50000000 ,BGN_DT ,PIN_SOVR_NUM + 50000000 ,END_DT ,ENTRY_TYPE_SOVR ,SOVR_VAL_CHAR ,SOVR_VAL_NUM ,SOVR_VAL_DT FROM PS_GP_PYE_OVR_SOVR
You can use the View Element Relationships utility to view hierarchical maps, including a map that existed as of a specific date.
This section discusses how to:
View elements used by a focus element.
View elements that use a focus element.
Page Name |
Object Name |
Navigation |
Usage |
GP_PINTREE_EFFDT |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, View Element Relationships, Uses |
View a map of elements that a focus element uses. The element relationship map must be built before the data is displayed. |
|
GP_PINTREE_EFFDT2 |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, View Element Relationships, Used By |
View elements that use the focus element. |
Access the Uses page.
Element maps include fields that contain PIN_NUM only. So, when looking at the map for an entitlement element, you don’t see fields for frequency, currency, and other non-element information.
Element Name |
Displays the name of the element that you selected on the search page. This is the focus element. |
Type |
Displays the element type of the focus element. |
As Of Date |
To see the relationship map that was in effect on a specific date, enter the date in this field. |
Element Uses |
Click the element name to view its member elements. This information appears in a tree structure that expands or collapses as you click the + or − folder before an element name. |
Perspective
To see additional information on a related element, click the element name in the Element Uses group box and select a view in the Perspective field.
Perspective |
Select the format for the data in this group box. Values are: Functional: Displays descriptive names of the data. Technical: Displays technical names for the data. |
Type |
Functional: Displays the name of the element type for the selected element. Technical: Displays the 2 character code of the element type for the selected element. |
Name |
Displays the name of the selected element. (The name is the same for the functional and technical views.) |
Description |
Displays the description of the selected element. (The description is the same for the functional and technical views.) |
Record |
Functional: Displays the descriptive name of the record in which the selected element resides. Technical: Displays the technical name of the record in which the selected element resides. |
Field |
Functional: Displays the descriptive name of the field that stores the element's value. Technical: Displays the technical name of the field that stores the element's value. |
Access Used By page.
This page resembles the Uses page but shows all elements that use the focus element.
See Also
Viewing Elements Used by a Focus Element
Absence Management offers a streamlined package creation process that enables you to create rule packages, create import/export scripts, and export rule packages using a single component for both standard and version based rule packages. You can run each step in this process—from package creation, to script creation, to package export—as part of a continuous sequence of steps, or run one step at a time. The Absence Management system ensures that each step is complete before the next step begins, and displays the status of the package so that you can track your progress through the export process.
In addition, Absence Management enables you to specify a default location on the Installation Settings page for the scripts used in the import/export process so that you do not need to enter the same basic information each time you export a package.
This section provides an overview of how to create and export rule packages, and discusses how to:
Name rule packages.
Select elements for a rule package by element.
Select elements for a rule package by attribute.
Select elements for a rule package by version.
Modify the SQL Where clause for selection criteria.
Create packages and scripts, and export packages.
View the elements in a rule package.
View version details for a package by version.
View the status of a package.
View a script.
To create and export a rule package:
Note. Rule packages can only include elements defined in records having PIN_NUM as the key.
Define criteria for selecting the elements in a rule package.
You can define different kinds of selection criteria:
Use the Define Criteria By Element page of the Create/Export Rule Package (GP_PKG_CREXP) component to select elements for a package by name.
Use the Define Criteria By Attribute page of the Create/Export Rule Package component to select elements by attribute (element type, owner, used by, class, category, country).
You can modify the SQL code that the system uses to select elements when you define criteria by attribute.
Use the Define Criteria By Version page of this component to select elements for a package based on their version number.
You can specify criteria by element and by attribute for the same package. If you do this, the system selects all elements that meet the criteria specified on the Define Criteria By Element page or the Define Criteria By Attribute page.
You cannot define criteria by version for a package together with criteria by element and/or by attribute. Version criteria are exclusive of other selection criteria.
Run the create package process to package the elements meeting the selection criteria.
Do this on the Package Processing page of the Create/Export Rule Package component.
View the package and clear any elements that you do not want to move to the target database.
Do this on the View Package page of the Create/Export Rule Package component
Run the create scripts process.
Do this on the Package Processing page.
Note. The system generates three scripts for the export and import process: xxx_exp.dms (export script), xxx_imp.dms (import script), and gp_cleanup.dms (cleanup script), where xxx represents the name of the rule package.
Review the scripts created in step 4 (above).
Do this on the View Scripts page of the Create/Export Rule Package component.
Run the export package process.
Do this on the Package Processing page.
You must export the package before you can import it into the target database.
Note. This section represents the create rule package, create import/export scripts, and export rule package steps as separate, discrete processes; however, you can also run these steps as part of a single continuous process.
Warning! If you add or change an element after creating a package, you must recreate the package to include the element.
Page Name |
Object Name |
Navigation |
Usage |
GP_PKG_DFN |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Create/Export Rule Package, Package Definition |
Name a rule package and enter a description and comments. |
|
GP_PKGCRIT_ELM_SEC |
Click Define Criteria By Element link on the Package Definition page. |
Define selection criteria for a package by element. |
|
GP_PKGCRIT_ATR_SEC |
Click Define Criteria By Attribute link on the Package Definition page. |
Define selection criteria for a package by attribute. |
|
GP_PKGCRIT_VER_SEC |
Select the Version Based check box on the Package Definition page and click the Define Criteria By Version link. |
Define selection criteria for a package by version. |
|
GP_PKG_CRIT2_SEC |
Click the Show Where Clause link on the Define Criteria By Attribute page. |
View and modify the SQL Where clause for the selection criteria defined on the Define Criteria By Version page. |
|
GP_PKG_S_RUNCTL |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Create/Export Rule Package, Package Processing |
|
|
GP_PKG_VIEW |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Create/Export Rule Package, View Package |
View the elements in a rule package. View the action (upgrade or delete) that the system takes when you copy the package. You can cancel elements in the package. |
|
GP_PKG_VERDTL_SEC |
Click the View Version Detail link on the View Package page for a package by version. |
View version details for a package by version. |
|
GP_PKG_DTTM_SEC |
Click the Package Status link on the Package Processing page. |
View the date and time a package was created, exported, imported, compared, and upgraded. |
|
GP_PKG_SCRIPTS_SEC |
Click the View Scripts link on the Package Processing page. |
View export, import, and cleanup scripts. |
Access the Package Definition page.
Enter a description of the package and comments.
Description and Comment |
Enter a description of the package and comments. |
Version Based and Define Criteria By Version |
Select the Version Based check box to define a package using version criteria. By default, this check box is cleared. When you select this check box, the Define Criteria By Version link appears and the Define Criteria By Element and Define Criteria By Attribute Links disappear. Click the Define Criteria By Version link to access the Define Criteria By Version page, where you can specify the version of the elements that you want to include in the rule package. |
Define Criteria By Element |
Click to access the Define Criteria By Element page, where you can select elements to include in the package by name. Note. When you specify the elements to include in the package on the Define Criteria By Element page and click OK, the check box in front of this link is automatically selected. |
Define Criteria by Attribute |
Click to access the Define Criteria By Attribute page, where you can select elements to include in the package based on attributes of the elements. Note. When you define element attributes on the Define Criteria By Attribute page and click OK, the check box in front of this link is automatically selected Note. You cannot define version based criteria for a package together with element or attribute criteria, as these package types are mutually exclusive. The system provides the following controls to prevent this from occurring: After you define and save version criteria for a package, you cannot access the Define Criteria By Element or Define Criteria By Attribute pages to add element and attribute criteria. In addition, if you try to combine package types before saving your work—for example, you define a version based rule package and then try to define additional criteria by element or by attribute—all of the version criteria you have already entered will be deleted at save time and you will receive a warning message. |
Note. After you import a package, the Define Criteria By Element, Define Criteria By Attribute, and Define Criteria By Version links are disabled and you can no longer modify the selection criteria.
Access the Define Criteria By Element page.
Packaging Criteria - Element List
Entry Type |
Select the entry type for the element to include in the package. This determines which elements you can select in the Element Name field. |
Element Name |
In this required field, select the name of the element to include in the package. This element is referred to as the focus element. |
Element Owner |
Identifies who created the element that you selected in the Element Name field and who’s responsible for maintaining it. Valid values are Customer, Modified, PS Mnt (PeopleSoft Maintained), PS NonMnt, and PS Secure. |
Include |
Select the elements to include in the package. Values are: Focus Element + Members: The system includes focus elements (the elements in the Element Name field) as well as any member elements used by the focus elements (as depicted on the Uses page). Focus Element Only (default): The system includes focus elements as well as any auto-generated components and accumulators. First level elements are selected as information only elements. Warning! Select Focus Element Only only if you know that the target database contains all the member elements. If it doesn’t, the system reports an error during the compare process. Note. The system always includes information for the member elements in the package—even when you select Focus Element Only. Although the member elements aren’t copied to the target database, the system uses the information to perform the Compare process described later in this chapter. |
Language |
Specify whether to copy base and related language data to the target database. All fields on GP_PIN that are translatable have associated related language data. Related language data is stored on the related-language table for GP_PIN, GP_PIN_LANG. Valid values are:
|
Action |
Select the action the system should take with this element when upgrading the target database. Values are: Upgrade (default): Adds the element to the target database or updates a matching element that’s in the target database. Delete: Deletes the element from the target database. (One database can be used as both the source and target database.) You cannot delete elements that meet any of the following conditions:
Note. You can delete the related language or all language information but not the base language alone. Warning! PeopleSoft strongly recommends that you place deletes in a separate package from all other elements. |
See Also
Access the Define Criteria by Attribute page.
Attribute Set1
Select the Attribute Set1 tab.
Include |
Specify whether the package includes only focus elements (which meet the selection criteria on the Attribute Set1 tab) or also includes elements that are used by the focus elements. Values are Focus Element + Members and Focus Element Only. Focus Element + Members: The system includes focus elements (in the Element Name field) as well as any member elements used by the focus elements (as depicted on the Element Relationship Uses page). Focus Element Only (default): The system includes focus elements as well as any auto generated components and accumulators. First level elements are selected as information only elements. Information only elements are used by the focus element and its immediate children (if this information has not been previously selected). Warning! Select Focus Element Only only if you know that the target database contains all the member elements. If it doesn’t, the system reports an error during the compare process. Note. The system always includes information for the member elements in the package—even when you select Focus Element Only. Although the member elements aren’t copied to the target database, the system uses the information to perform the compare process described later in this chapter. |
Language |
Specify whether to copy base and related language data for GP_PIN fields to the target database. All fields on GP_PIN that are translatable have related language data. This data is stored in the related-language table for GP_PIN, GP_PIN_LANG. Values are:
|
Action |
Select the action the system should take with this element when upgrading the target database. Values are: Upgrade (default): Adds the element to the target database or updates a matching element that’s in the target database. Delete: Deletes the element information from the target. You cannot delete elements that meet any of the following conditions:
Note. You can delete the related language or all language information but not the base language alone. Warning! PeopleSoft strongly recommends that you place deletes in a separate package from all other elements. |
Element Type |
Select the element type. |
Element Owner |
Select the element owner. Valid values are: Customer, Modified, PS Mnt, PS Non-Mnt, and PS Secure. |
Attribute Set2
Select the Attribute Set2 tab.
Used By |
Select where elements are used. Valid values are All Countries (default) and Specific Country. If you select Specific Country, you must select the country in the Country field. |
Country |
Select the country's three-digit country code if you selected Specific Country in the Used By field. |
Category |
To select only elements assigned to a particular category, select the category. (You assign a category to an element on the Element Name page.) |
Element Class |
Select the element class to package. (You assign an element class to an element on the Element Name page.) Valid values are: Customary, Not Classified, Sample Data, Statutory, and System Data. |
Where Clause Option |
The system converts the criteria entered on the Define Criteria by Attribute page into SQL in order to select elements for the package. Values are: Use Default WHERE Clause: Tells the system to use the default Where clause. If the where clause has been changed and Use Default WHERE Clause is selected again, the page discards any SQL code modifications you have made and reverts to the Where clause based on the criteria you specified. Change WHERE Clause: Makes all other fields on the page unavailable and puts the SQL code on the Where Clause page in edit mode. |
Show Where Clause |
Displays the Where Clause page, where you can view and alter the SQL code for your selection criteria. |
See Also
Selecting Elements for a Rule Package By Element
Access the Where Clause page.
Where Clause Option |
Select Use Default WHERE Clause to use the default clause or revert to it after editing the SQL code. Any edits you make to the Where clause will be lost when you select Use Default WHERE Clause. Select Change WHERE Clause to make the code on the lower part of the page available for editing. |
Where Clause |
If you select Use Default WHERE Clause as the Where Clause Option, the system displays the Where clause of the SQL statement that it created based on the selection criteria defined on the Define Criteria by Attribute page. The Where clause is not editable. If you select Change Where Clause, you can edit the SQL Where clause. The following rules apply:
Note. When you Click OK and save, the system checks for the use of PIN_NUM, and looks for SQL syntax errors. |
Access the Define Criteria By Version page.
Used By |
Select All Countries or Specific Country depending on whether you are defining version criteria for all countries or a single country. |
Specific Country |
If you select Specific Country in the Used By field, specify the country. |
Version |
Select the version of elements to include in the package. You can select multiple versions if they are for the same country. |
Access the Package Processing page.
After defining selection criteria for a package, use the Package Processing page to:
Create packages based on the selection criteria you have defined.
Create scripts to use in the export and import process.
Export packages to the target database.
Track the status of a package.
During the export process, the system automatically adds 50 000 000 to the value of the PIN number assigned to each element so that it can distinguish the imported elements from elements that exist in the target database.
Processing Options
The check boxes under Processing Options display the status of the creation and export process. Status values are:
Created: If this check box is selected, the package has been created.
Scripts Created: If this check box is selected, scripts have been created for the package.
Exported: If this check box is selected, the package has been exported to the target database.
Package Status |
Click to access the Package Status page, where you can view the date and time packages and scripts were created, and see when packages were exported, imported, compared, and upgraded. |
Create Processing
Create Package |
Select Create Package to have the program create the package based on the criteria, attributes, or version you have defined. |
Export Processing
Create Scripts |
Select Create Scripts to have the system to generate three scripts for the export and import process: xxx_exp.dms (export script), xxx_imp.dms (import script), and gp_cleanup.dms (cleanup script), where xxx represents the name of the rule package. This check box becomes available under the following conditions:
Note. You must specify a path to the script location to generate a script. Note. You can select Create Package and Create Scripts at the same time, and the system will generate the package and then create the export and import scripts. However, you cannot select Create Scripts before you generate the package. |
Script Location |
Specify the path to the location where you want the scripts to be created. This field becomes available when you:
The location of the scripts and data files must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Scripts |
Click to access the View Scripts page, where you can review export and import scripts. |
Export Package |
Select Export Package to have the system export the package during processing. This field becomes available when you:
After exporting the package from the source database, you can import it into the target database using the Apply Rule Package (GP_PKG_APPLY) component. Note. During the export process, the system automatically adds 50 000 000 to the value of the PIN number assigned to each element so that it can distinguish the imported elements from elements that exist in the target database. |
Process
Click the Process button to call and run the processes denoted by the check boxes you have selected: Create Package, Create Scripts, and Export Package. Note that you can select all three check boxes at the same time and run these processes as a single, continuous sequence, or run one process at a time. However, the processes must run in the order of create package first, then create scripts, then export package.
Note. When you click the Process button the Process Monitor page appears, so that you can monitor the process. Wait until the program finishes before opening a page associated with the package.
Access the View Package page.
After creating a package, you can view the elements in the package and individually select any elements that you do not want to export to the target database.
Action |
Displays the action applicable to the element in your package. Values are: Upgrade, Delete, and Info Only. When deleting items, the source database and target database can be the same. |
Upgrade |
This check box is selected by default to include the element in the package for export. Clear it to exclude the element from the export. |
View Version Detail |
If the elements displayed on the View Package page are packaged by version, the View Version Detail link appears. Click this link to access the View Version Detail page, where you can view each element's version number and the database records (tables) containing the element definitions. |
Access the View Version Detail page.
For elements packaged by version, access the View Version Detail page to view each element's version number and the database records (tables) containing the element definitions.
Access the Package Status page.
View the date and time packages and scripts were created, and see when packages were exported, imported, compared, and upgraded.
Access the View Scripts page.
Script Location |
Displays the script location, which must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Package Script |
Select the type of script that you want to view: export, import, or cleanup. The DataMover script appears. |
Absence Management offers a streamlined package import and compare process that enables you to run the import, compare, and upgrade process using a single component for both standard and version based rule packages. You can run each step in this process—from package import, to comparison, to upgrade—as part of a continuous sequence of steps, or run one step at a time. The Absence Management system ensures that each step is complete before the next one begins, and displays the status of the package so that you know exactly where you are in the process.
In addition, Absence Management enables you to specify default packager-related options on the Installation Settings page so that you do not need to enter the same basic information each time you run the import, compare, and upgrade process. Use the Installation Settings page to:
Specify a default location for the scripts used in the import process.
Specify compare report print options for standard and version based rule packages to control the type of information that appears in the compare report.
Specify the conditions under which an upgrade is permitted—that is, you can elect to proceed with upgrades despite errors and warnings in the compare process, or choose not to allow upgrades containing errors or warnings.
See Defining Absence Management Installation Settings.
This section provides an overview of rule package, imports, comparisons, and upgrades, and discusses how to:
Import a package.
Run the compare report.
Start the compare and upgrade processes.
Review for upgrade errors.
After running the export process, use the Apply Rule Package (GP_PKG_APPLY) component to import the package into to the target database, compare the rules in the source database to those in the target database, and upgrade the rule package.
To import, compare, and upgrade a rule package:
Run the import process on the Package Processing page of the Apply Rule Package component.
Compare the packaged elements with the elements in the target database by running the compare process and generating the compare report on the Package Processing page of the Apply Rule Package component. Generating the compare report is optional.
The system determines which elements are new to the target database, which update existing elements in the target database, and which need deleting from the target database.
Review the compare report and the results displayed on the Package Elements and Package Compare Audit pages of the Apply Rule Package component to determine the results of the compare process.
On the Package Elements page you can exclude elements from the upgrade process.
Resolve warnings and errors that are identified in the compare report, on the Package Elements page, and on the Package Compare Audit page during the compare process.
Warnings and errors can occur for several reasons. For example, the source element could use other elements that don’t exist in the target database and are not included in your package or an element that you want to delete could be used in a results table. The corrective action depends on the type of error and warning.
Rerun the compare process on the Package Processing page after correcting errors or excluding elements from the package.
Run the upgrade process after deciding whether to proceed with errors and/or warnings.
Do this on the Package Processing page.
During the upgrade process the system:
Updates the imported elements with the correct PIN number if they already exist in the database.
Assigns new numbers to the new elements.
Deletes rows according to the option chosen in the package.
You can run this process only once.
Note. This section presents the package import, comparison, and upgrade steps as separate, discrete processes; however, you can run these steps as part of a single continuous process.
Note. Before moving multiple elements simultaneously, it is recommended that you back up the target database.
What Happens During the Compare Process
For each exported element, the system looks for an element in the target database with the same PIN code, element type, and element owner.
This flowchart shows the logic that the system uses to perform the comparison and generate the resulting warning or error messages:
Compare process for rule packages (flowchart 1)
Compare process for rule packages (flowchart 2)
Warning! Upgrades override elements in the target database with the information that has been sent over from the source.
See Also
You can generate a compare report while performing the compare process. The compare report enables you to see what elements the Rule Package will change on a field-by-field basis. Use this information to decide whether to upgrade a specific element.
The compare report creates a report displaying the affected elements and what the differences are between the elements in the Rule Package and the elements in the target database. The compare report can only be run at the same time as the compare process.
Compare Report Summary Page
The summary page is the first page of the compare report. It includes the following information:
Type of rule package (regular or version based).
Version of the elements included in the rule package if the package is version based.
The names of the source and target databases.
The date and time that the import and compare processes were run.
The countries with elements included in the package.
The total number of elements in each of these categories listed below, depending on the Compare Report Print Options selected on the Package Processing page:
Elements with errors/warnings.
Modified elements.
New elements.
Deleted elements.
Unchanged elements.
Note. These totals are for all of the elements in a package except those that are for information only, and are not separated by country. The exception to this rule is that the total for errors/warnings includes informational elements.
Compare Report Body
The body of the compare report consists of four columns. The columns and contents are described in the following table:
Column |
Contents |
Elements |
Note. Upgrade action, upgrade, compare status, and error or warning messages appear only on the Elements With Error/Warning Messages page of the report. |
Record.Field |
Record and field name for the values contained in the Source Database and Target Database columns. |
Source Database |
Data values that are moving from the source to the target database as part of the Rule Package for the applicable record or field name. |
Target Database |
Data values that are currently in the target database for the applicable record or field name. |
Note. Elements in the compare report are displayed based on the alphabetical order of their country codes. For example, elements for CHE (Switzerland) appear before elements for DEU (Germany). The country code All (Across All Countries) appears if there is an element in the package that is defined for All countries or is in error/warning status.
Elements Displayed in the Compare Report
The compare report is made up of different sections containing detailed information about different categories of elements:
Elements with Errors or Warnings — All elements that have an error or warning message appear in this first section with basic information about the element (if it is available). All errors and warnings should be looked into and resolved before continuing the upgrade process.
Modified Elements — This section is for modified elements and displays the rows (records and fields) that will be changed in an upgrade. If a new row of data is being added, it also appears in this section.
Important! The element definition tables for array, bracket, formula, fictitious calculation, and historical rule elements include a sequence number field. This field is not always displayed online and has a purely technical function; however, you may see these elements appearing in the compare report as modified due only to changes in their sequence number. This is expected, as the report provides a field-by-field comparison. If the report lists these elements as modified, you should determine whether fields and information other than sequence number have changed (as this is what is critical from a functional perspective). If only the sequence number has changed, there will be no functional impact from an upgrade to these elements.
Important! Rate Code elements are keyed by both PIN Number (PIN_NUM) and HR Compensation Rate Code (COMP_RATECD). As a result, if the HR Rate Code is changed in an element definition, you will see this displayed in the modified elements section of the compare report as a new row (with 2 key fields appearing) and a deleted row (with 2 key fields appearing).
New Elements — This section is for new elements in the rule package (elements that are not in the target database), and displays the following fields from GP_PIN: PIN Code (as the key field); PIN_NM; DESCR; COMMENTS.
Deleted Elements — This section is for deleted elements, and displays the following fields from GP_PIN: PIN Code (as the key field); PIN_NM; DESCR; COMMENTS.
Elements with no changes — Only pin code and element name are displayed in this section.
Note. These report sections are displayed country by country in alphabetical order of the country codes. For example, report sections for CHE (Switzerland) appear before those for DEU (Germany). If you request a report section and there are no elements belonging to that category, the following message appears in that section of the compare report: “There are no elements that qualify for this section.” For country code ‘All’ (Across All Countries), the report sections only print out if there are elements to report on. No page is printed if no elements exist for ‘All’ in the section—not even the message noted above appears. Country code ‘All’ pages always appear at the end of the report.
Note. For formulas, only the formula text is displayed, rather than details about each individual field.
For all PIN Number fields, the compare report displays the corresponding PIN Code instead of the PIN Number.
Note. In the compare report, record information is printed in the following sort order: GP_PIN (if applicable), Parent Element Definition Record (if applicable), and Child Element Definition Records (if applicable). Within each of these records, the data displayed is sorted by effective-date descending (if effective date is in the record) and then by key fields ascending.
Page Name |
Object Name |
Navigation |
Usage |
GP_PKG_DFN |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Apply Rule Package, Package Definition |
View the description and package ID of a rule package. |
|
GP_PKG_T_RUNCTL |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Apply Rule Package, Package Processing |
|
|
GP_PKG_ELEM_UPG |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Apply Rule Package, Package Elements |
View the results of the Compare processes and exclude elements from the Upgrade process. |
|
GP_PKG_CMP_AUDIT |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Apply Rule Package, Package Compare Audit |
Review for errors that occur during the Compare process. Before continuing with the Upgrade process, correct the errors and rerun the Compare process. |
|
GP_PKG_DTTM_SEC |
Click the Package Status link on the Package Processing page. |
View the date and time a package was created, exported, imported, compared, and upgraded. |
|
GP_PKG_SCRIPTS_SEC |
Click the View Scripts link on the Package Processing page. |
View export, import, and cleanup scripts. |
Access the Package Definition page.
View the Package ID and description of the package you are comparing and upgrading.
Access the Package Processing page.
Access this page from the target database.
Use this page to import, compare, and upgrade rule packages and to track the status of an upgrade.
Processing Options
The check boxes under Processing Options display the status of the upgrade. Status values are:
Imported: If this check box is selected, the package has been imported into the target database.
Compared: If this check box is selected, the elements in the package have been compared with those in the target database.
Upgraded: If this check box is selected, the target database has been upgraded with the elements in the package.
Package Status |
Click to access the Package Status page, where you can view the date and time packages and scripts were created, and see when packages were exported, imported, compared, and upgraded. |
Import Processing
Import Package |
Select Import Package to instruct the system to import the elements in the package into the target database during processing. You must specify a path to the scripts used to import the package. This check box is always enabled, regardless of whether the package has already been imported. |
Script Location |
Specify the path to the location where you want the scripts to be created. The location of the scripts and data files must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Scripts |
Click to access the View Scripts page, where you can view the export, import, and cleanup scripts. |
Compare Processing
Compare Package |
Select Compare Package to have the system compare the imported elements with those in the target database during processing. This check box is enabled when:
When the compare process is complete, check the Package Upgrade tab on the Package Elements tab and then review the Package Compare Audit page for errors. |
Create Compare Report |
Select to generate a report comparing elements in the rule package to the elements in the target database on a field-by-field basis. This check box is enabled when you select the Compare Package check box. |
Update Statistics |
Select to update statistics in the appropriate tables when running the compare process. |
Compare Report Print Options |
These check boxes determine what data appears in the compare report.
Note. You can set default print options for the compare report on the Installation Settings page. You can override these defaults when you run the compare process on the Package Processing page. |
Upgrade Processing
Upgrade Package |
Select Upgrade Package to have the system upgrade the target database with the elements in the package during processing. This check box is enabled when:
This process upgrades only those elements that pass the compare process without errors. You can upgrade a package only once. Note. The upgrade process will not be completed if there are errors or warnings—unless you select upgrade with errors and/or warnings. If you choose not to upgrade with errors and warnings and there is an error or a warning, the process monitor will show success but the message
log will display one of the following messages: Important! Do not run the compare and upgrade processes together with regular payroll processes. This is to avoid affecting other users. |
Update Statistics |
Select to generate and view statistics on the upgrade process. This check box becomes available when you select Upgrade Package. |
Continue Upgrade Processing |
Select With Errors and/or With Warnings to proceed with the upgrade despite errors and warnings in the compare report. If you do not select one or both of these options, and there are errors or warnings, the process will not upgrade. The process will run to success but a message will be generated with information about the errors or warnings. These check boxes become available when the Upgrade Package check box is selected. Note. Even with the With Errors check box selected, elements that are in error are not included in the upgrade—only elements in the package that are not in error are upgraded in the target database when you run the upgrade process. By contrast, selecting the With Warnings check box does not prevent an element with an associated warning from being included in the upgrade if the upgrade check box is selected. However, if you do not select With Errors and/or With Warnings, and there is even a single error or warning, the process will not upgrade. The process will run to success but a message will be generated with information about the errors or warnings. Note. You can set default options for continuing an upgrade on the Installation Settings page. You can override these defaults when you run the upgrade process on the Package Processing page. |
Process
Click the Process button to call and run the processes denoted by the check boxes you have selected: Import Package, Compare Package, and Upgrade Package. Note that you can select all three check boxes at the same time and run these processes as a single, continuous sequence, or run one process at a time. However, the processes must run in the order of import first, then compare, then upgrade.
Note. When you click the Process button the Process Monitor page appears, so that you can monitor the process. Wait until the program finishes before opening a page associated with the package.
Access the Package Elements page.
This page displays the results of the compare process. If failures are reported, correct the errors before continuing with the upgrade. The Package Compare Audit page provides additional information about the errors.
Source PIN Number (source pay item name number) |
Displays the PIN number of the element from the source database (without an added 50 000 000). |
Element Name |
Displays the name of the element in the source database. |
Upgrade |
Select this option to overwrite the element with the data from the source database. If you modified the target element then your changes will be lost. To exclude the element from the upgrade process, clear the check box. Excluded elements will retain any changes you may have made. Important! If you exclude an element from the package, you must rerun the compare process before resuming the upgrade. |
Result |
Displays the result of the comparison. Values are: Not Done: You haven’t yet run the compare process. Success: The compare process encountered no errors. Failure: The compare process failed. The Reason field shows why. Warning: The PeopleSoft system has modified the element in the source database (the upgrade flag is checked on) or you have taken control of the element ownership (the upgrade flag is checked off). The Reason field explains the reason for the warning. In order to accept or ignore the change, update the upgrade flag to indicate whether you want the element upgraded. Note. Failures are listed first, followed by warnings and then successes, so if the entries on the first page all read Success, you can assume that the entire comparison process succeeded. |
Reason |
If the compare process failed or generated a warning, one of the following reasons appears here: New Element Not Copied Completely: You’re trying to copy a new element into the target database but that element has no GP_PIN record—only a definition. (For example, you stamp and package elements by version. Another person modifies the element and clears the version number.) Restamp the element with the appropriate version and export it again. Note. This error occurs when an element is new and only GP_PIN is brought in and not the definition, or when the definition is there but not GP_PIN. Element Owner / Type Conflict: The PIN code for the source element matches a PIN code in the target database, but the owner or element type doesn’t match. Use the Element Rename page to change the PIN code in the target database. If an element is customer-defined, the Element Owner field on the Compare and Upgrade Package - Package Elements page reads Customer. Member Element not found: The source element uses other elements that don’t exist in the target database and aren’t included in the package. Remove the element from the upgrade process by clearing the Upgrade check box, or include the missing elements in the packaging criteria, recreate the package in the source database, and re-import it. Mbr Element Owner/Type Conflict (member element owner/type conflict): This is similar to the Element Owner/Type Conflict message but applies to a member element that’s used by the focus element. Use the Element Rename page to change the PIN code in the target database. Element does not exist: You’re trying to delete an element that’s not in the target database. PS Delivered/Customer Modified: This warning indicates that the element in the target database has been modified and no longer matches the element in the source database. To accept the PeopleSoft or customer modifications and overwrite any changes in the target database, select the Upgrade check box. The element ownership remains PS Delivered/Customer Modified once the check box is selected. PS Delivered/PS Modified: This warning indicates that the PeopleSoft system has changed the ownership of the element in the source database so that it’s no longer PeopleSoft delivered or maintained. To reject the change, clear the Upgrade check box. Cannot delete PS-Owned Element: You’re trying to delete a PeopleSoft-owned element from the target database. You cannot delete such elements. Duplicate Package Element Found: You’re trying to import an element that is in another package that’s being upgraded. Used in Non-Elem Defn (element definition): You are trying to delete an element that is used in a non-element definition. Modify the non element definition so that it no longer uses this element. Used in Output Results: You are trying to delete an element that is used in a processing result table. (Results cannot be deleted from the result tables.) Used in Payee Data: You’re trying to delete an element that’s associated with payee data. Modify the payee data so that it no longer uses this element. Used in Rule Defn (definition): You are trying to delete an element that is used by another element. Modify the rule definition so that it is no longer uses this element. Auto-component used in RuleDfn (rule definition): You are trying to delete an element whose component is used by a rule definition. Modify the element definition so that it is no longer uses this component. |
New Element |
The check box is selected if the element to be upgraded isn’t in the target database. |
Upgrade Status |
Indicates whether the upgrade process has occurred. Changes from Not Done to Done after you complete the compare and upgrade processes. |
Access the Package Compare Audit page.
Parent |
Displays the name of the parent element. |
Member Element |
Displays the name of the member element that generated the error. |
Failure Reason |
Displays the cause of the failure. The same information appears in the Reason field on the Package Elements tab. |
Upgrade Action |
Displays the action that the system was trying to take when the error occurred. Values are: Upgrade, Delete, and Info Only. |
Package Upgrade
Select the Package Upgrade tab.
Parent |
Displays the name of the parent element that generated the error. |
Member Element |
Displays the name of the member element that generated the error. |
Record (Table) Name |
Displays the name of the record that stores the parent element and its members. |
PIN Num Fieldname (pay item name number field name) |
Displays the name of the field that contains the key field. |
Field Name |
Displays the name of the field that contains the member element that created the error. |
Access the Package Status page.
View the date and time packages and scripts were created, and see when packages were exported, imported, compared, and upgraded.
Access the View Scripts page.
Script Location |
Displays the script location, which must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Package Script |
Select the type of script that you want to view: export, import, or cleanup. The DataMover script appears. |
This section provides an overview on how to rename elements, and discusses renaming an element.
Sometimes the compare process finds an element in the target database whose PIN code is the same as the source element’s, but the two elements have different element types or owners. In this case, you receive one of the following error messages: “Element Owner/Type Conflict” or “Mbr Element Owner/Type Conflict.”
To continue exporting the element, you can use the Element Rename Utility to change the PIN code of the target element. After changing the PIN code, always rerun the compare process.
When you instruct the system to change an element’s PIN code, it checks the following:
Is the new PIN code already in use?
If yes, the system generates an error.
Is the old PIN code used in PeopleSoft Enterprise Time and Labor?
If yes, the system creates a warning. Remap the element in Time and Labor to reflect the new code.
Is the new PIN code the same as the old PIN code?
If yes, the system issues a warning.
Important! Do not rename an element when you are in the process of creating a package.
PeopleSoft created elements cannot be renamed.
Warning! Time and Labor stores PIN code information, so if you make a change, you must update Time and Labor data accordingly.
See Also
Page Name |
Object Name |
Navigation |
Usage |
GP_PIN_RENAME |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Rename Element Codes, Element Rename |
Change an element’s PIN code. |
Access the Element Rename page.
New PIN Code (new pay item name code) |
Enter the new code. The old PIN code is replaced when you save. Note. When renaming a PIN, make sure that you use the PIN name plus the country suffix. For example: PIN NAME DEU. |
This section provides an overview of creating and exporting non-rule packages and discusses how to:
Name non-rule packages.
Define selection criteria.
Modify the SQL Where clause for the selection criteria.
Display elements of a non-rule package.
Export and import non-rule packages.
View non-rule package scripts.
Non-rule packages contain both non-elements and element information. Non-elements are those that belong to records where PIN_NUM is not the primary key.
Important! When creating a non-rule package, make sure that records that are related to the record you are moving are included in the same package. To move a complete set of related data, you need to understand which records are related.
Before moving non-rule data, make sure that the elements that are associated with the non-rule data exist in the target database. You can do this by creating a rule package that contains the elements that are associated with the data record that’s being moved and copying (upgrading) the rule package to the target database.
For example, suppose that you are moving non-rule calendar detail records. Calendar details are associated with the process number element (PIN_PRC_NUM). Before moving the calendar data, create a rule package that contains the process number element and move it to the target database. The system can assign a new PIN number to this element in the target database, if necessary. Once this package is in the target database, you can move the calendar details by creating a non-rule package.
When the system moves the calendar details, it finds the process number element in the target database, retrieves the new PIN number that was assigned during the rule upgrade process, and renumbers the process number PIN in the calendar detail record. (Without renumbering, the calendar detail would contain PIN numbers that may not exist or are not related the element used by that calendar in the target database.)
To create and export a non-rule package:
Create the non-rule package.
To do this, use the Create Non-Rule Package (GP_NR_PKG_CREATE) component.
On this component you can:
Define the selection criteria for the records to move from the source database.
Run the create package process.
View the rules that are associated with the data that you’re moving.
Export the non-rule package.
To do this, use the Export Non-Rule Package (GP_NR_PKG_EXPORT) component.
The system exports the non-rule data and the element information contained in the non-rule package.
Note. Absence Management enables you to specify a default location for the scripts used in the export non-rule package process so that you do not need to enter the same basic information each time you export a package. To do this, access the Installation Settings page for Absence Management (Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, System Settings, Installation Settings) and specify the script location.
Access the Package Definition page.
Enter a description of the package and comments.
Access the Package Criteria page.
Package ID |
Displays the package ID. |
Record |
Select the record that contains the data to move. The Data Selection group box becomes available. |
Where Clause Option |
The system converts the criteria entered on this page into SQL in order to select elements for the package. Values are: Use Default WHERE Clause: Tells the system to use the default Where clause. If the where clause has been changed and Use Default WHERE Clause is selected again, the page discards any SQL code modifications you have made and reverts to the Where clause based on the criteria you specified. Change WHERE Clause: Makes all other fields on the page unavailable and puts the SQL code on the Package Records page in edit mode. |
Data Selection
Use the fields in the Data Selection group box to indicate which data to move. Selection criteria are optional, but if you don't enter selection criteria, no delete process is performed on the target database before source data importation. This can result in a “Duplicate Record” message from Data Mover during import, or it can cause the upgrade process to fail.
Field Name |
Select the field on which to base the selection criteria. (It is advisable to use a key field, which are identified in the prompt table’s Key Position column.) |
Field Format |
Displays the format of the field that you selected. |
Operator |
Select the operator that the system uses to select the data to include in the package. Values are <, <=, <>, =, >, >=, and LIKE. If you select LIKE, you can enter a partial value, such as S, in the field to the right. In the field on the right of the Operator field, enter the value the system searches for. (The name of this field varies with field format.) |
Create Package |
Click to create the package after defining the selection criteria. The Create Non-Rule Package - Package Records page appears when the package is created. To review the package contents, select the Package Elements tab. |
Access the Create Non-Rule Package – Package Records page.
Record |
Displays the record from which fields are selected. |
Where Clause Option |
Select a Where clause option. Values are: Change WHERE Clause: Select to edit the SQL code on the lower part of the page. Use Default WHERE Clause: Select to use the default clause or revert to it after editing the SQL code. Changes that you have made to the Where clause are lost and the field is disabled. |
Where Clause |
If you selected Use Default WHERE Clause in the Where Clause Option field, the system displays the Where clause of the SQL statement it created based on the selection criteria that you entered for the package on the Create Non-Rule Package - Package Criteria page. This WHERE clause cannot be edited. If you selected Change Where Clause, you can edit the SQL. Do not use PIN_NUM as a selection criterion or any field where PIN_NUM can be stored. (Doing so prevents renumbering during the import process.) |
Access the Package Elements page.
Note. This display page lists the rule elements used in the records being moved to the new database. These are informational elements. The page doesn’t show data in records where PIN Num is not a field.
Access the Export Non-Rule Package - Package Records page.
Script Location |
Specify the path to the location where you want the import/export scripts to be created when you click the Create Scripts button. The location of the scripts and data files must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
Record |
Displays the name of the record containing the data that you’re exporting. |
Where Clause |
Displays the Where clause of the SQL statement that selects the data to be exported. |
Create Scripts |
Click to create the import and export scripts for the non-rule package: xxx_elements_imp.dms, xxx_elements_exp.dms, xxx_records_exp.dms, and xxx_record_imp.dms (where xxx = name of package). The scripts will be created in the script location you specify. |
Export |
Click to export the package once you have selected a script location. |
Access the View Scripts page.
Script Location |
Displays the script location, which must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Package Script |
Select the type of script that you want to view: either export or import scripts for the elements and records. The DataMover script appears. |
Access the Package Status page.
View the date and time a package was created, exported, imported, compared, and upgraded.
This section provides and overview of comparing and upgrading non-rule packages and discusses how to:
Import non-rule element information.
Compare non-rule packages with the data in a target database.
Import non-rule records.
Upgrade non-rule packages.
After creating and exporting a non-rule package:
Import the non-rule elements.
To do this, use the Import Non-Rule Elements (GP_NR_PKG_IMPORT) component.
The system imports the element information only—not the elements themselves.
Compare the elements in the non-rule package with those in the target database to ensure that the non-rule elements are in the target database.
To do this, use the Compare Non-Rule Package (GP_NR_PKG_COMPARE) component.
Using this component you:
Compare the element information in the package with the element information in the target database.
Identify any missing elements that need to be moved into the target database.
Import the non-rule records.
To do this, use the Import Non-Rule Records (GP_NR_PKG_IMPRECS) component.
Upgrade to the non-rule package.
To do this, use the Upgrade Non-Rule Package (GP_NR_PKG_UPGRADE) component.
Note. Absence Management enables you to specify a default location for the scripts used in the import non-rule package process so that you do not need to enter the same basic information each time you import a package. To do this, access the Installation Settings page for Absence Management (Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, System Settings, Installation Settings) and specify the script location.
Access the Package Definition page.
Enter or view a description of the package and comments.
Access the Import Non-Rule Elements - Package Records page.
Script Location |
Displays the script location, which must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section titled The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
Import Package |
If the button is available, click to start the import process. |
Access the Compare Non-Rule Package - Package Elements page.
After completing the first part of the export and import process, log onto the target database and perform the compare process, which verifies that the elements needed by the data you’re moving exist in the target database. The compare process checks PIN code and PIN type.
If the elements don’t exist or if the element types do not match, the compare process fails and you must create a rule package and move the package to the target database before continuing with the non-rule upgrade.
Element List
This group box shows the results of the comparison of the source and target databases. If the compare process reports failures, correct the errors before continuing with the upgrade process.
Source PIN (source pay item name) |
Displays the PIN number of the element from the source database (without 50000000 added). |
Element Name |
Displays the name of the element in the source database. |
PIN Code (pay item name code) |
Displays the element’s PIN code. |
Element Type |
Displays the element’s type. |
Element Owner |
Identifies who created the element and who’s responsible for maintaining it. Valid values are: Customer, Modified, PS Mnt, PS NonMnt, and PS Secure. |
Result |
Displays the results of the comparison: Not Done: You haven’t yet run the compare process. Success: The compare process didn’t encounter any errors. Failure: The compare process failed. The Reason field shows why. |
Reason |
If the compare process failed, displays one of the following values: Not Found: Create a new rule package that includes the missing elements and move the package to the target database before continuing with the non-rule upgrade. Type Cnflt (type conflict): The element types do not match. Most likely this error occurred because you created an element that has the same PIN code, but a different type. Rename your element and create a new rule package that includes the element that is being used. |
Compare |
Click to start the compare process. Once the process is complete, the Element List group box shows, element by element, whether a match was found. If the process generates no errors, the following message appears: “Compare process completed successfully. You can now import non-rule records from the source database.” |
Access the Import Non-Rule Records - Package Records page.
After reviewing the results of the compare process and moving any missing elements into the target database, you can import the non-rule records into the target database.
Click the Record Import button to import the records.
Access the Upgrade Non-Rule Package - Package Records page.
The final step is to renumber the elements on the non-rule data that you’ve imported so that they have the same PIN numbers as the matching elements in the target database, using the Upgrade Non-Rule Package component.
Upgrade |
Click to start the upgrade process. A message tells you when the process is complete. You cannot compare or upgrade the same package again unless you re-import records and elements into the target database. |
Access the View Script page.
Script Location |
Displays the script location, which must be accessible by both the import and export NT Process Scheduler for the import and export databases. You must specify the script location in the Process Scheduler configuration file (psprcs.cfg). Note. We discuss how to specify the script location in the Process Scheduler configuration file in the section called The Process of Connecting UNIX and NT Directories. See The Process of Connecting UNIX and NT Directories. Note. You can define a default script location on the Installation Settings page for all packager scripts. |
View Package Script |
Select the type of script that you want to view: export or import. The DataMover script appears. |
Access the Package Status page.
View the date and time a package was created, exported, imported, compared, and upgraded.
This section discusses how to:
Copy a rule package and its selection criteria.
Copy a non-rule package and its selection criteria.
Note. Copying packages alone does not prepare the package for export. You must also run the create rule or non-rule process, which attaches all elements to the package.
Page Name |
Object Name |
Navigation |
Usage |
GP_PKG_COPY |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Copy Rule Package, Copy Rule Package |
Copy an existing rule package and its selection criteria. This does not copy the element information. |
|
GP_NR_PKG_COPY |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Copy Non-Rule Package, Copy Non-Rule Package |
Copy an existing non-rule package and its selection criteria. This does not copy the element information. |
Access the Copy Rule Package page.
Copy To Package ID |
Enter up to eight alphanumeric characters for the new package ID. |
Copy Package Definition |
Click to copy the package. |
Access the Copy Non-Rule Package page.
See the field descriptions for the Copy Rule Package page.
See Also
Copying a Rule Package and Its Selection Criteria
This section provides an overview of stamping and packaging elements by version and discusses how to:
Stamp elements with a new version number.
Define version relationships.
Identify elements to package.
View version details.
Versioning is a way to track the elements that were delivered for each release or update and to package elements by version. For example, elements delivered with Absence Management 8.9 are labeled 8.90.00. Major releases, updates, and hot fixes typically require a new version of all or some previously delivered rules.
You can assign a version number (or label) to multiple elements and use the versioning utilities to package elements by version so that they can be moved to another database.
When you package elements by version, the system pulls the rows associated with the version that you specify. Once the elements are packaged, you can move them across databases, using the same procedures that apply to rule packages; you export the elements, compare them with existing elements in the database, and complete the upgrade.
To package elements by version:
Stamp the appropriate version number(s) on the elements that you want to package using the Version Stamping (GP_STAMPING) component.
Use the Define Criteria By Version page of the Create/Export Rule Package (GP_PKG_CREXP) component to define selection criteria for packaging the elements that you stamped in step 1.
Follow all other instructions presented earlier in this chapter for creating and exporting rule packages.
Follow the instructions presented earlier in this chapter for importing, comparing, and upgrading rule packages.
See Also
Page Name |
Object Name |
Navigation |
Usage |
GP_STAMPING |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Version Stamping, Version Stamping |
Stamp elements with a new version number, and initiate the stamping process. |
|
GP_VER_RULE_DFN |
Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Elements, Manage Global Payroll Packages, Define Version Relationships, Define Version Relationships |
View version relationships between element definition records. Displays the Rule Definition record and the corresponding child records. |
Access the Version Stamping page.
Use this page to stamp a version on elements that you add or modify or to restamp an existing version of an element.
Used By |
You can stamp elements that are applicable to all countries or limit the stamping to one country. If you select All Countries, the Country field defaults to All. If you select Specific Country, specify the country code in the Country field. |
Stamp Type |
Indicate the elements to stamp: Blank: Elements that have no existing version. Existing Version: Elements whose version is what you specified in the Existing Version field. Blank and Existing Version: Elements with no existing version and elements associated with the version that you specified in the Existing Version field. |
Existing Version |
Becomes available when you select Existing Version or Blank and Existing Version as the stamp type. Select from any existing version. The system looks for all elements associated with the version that you select. |
New Version |
Enter up to 16 alphanumeric characters for the name of the new version. The system adds the prefix C_ to the name if this is a customer installation. A package coming from the PeopleSoft system would have version numbers, preceded by P_. When using the User Version functionality provided on the Element Name page, the system adds the prefix INT_ to those versions. The Element name page is documented in another section of this PeopleBook. |
Stamp Global Payroll Records |
Click to initiate the stamping process. The system stamps the selected elements with the new version after clearing the existing Version entries, if any. |
Note. Versioning occurs only in element definition records (records with a primary key of PIN_NUM).
Access the Define Version Relationships page.
Rule Definition Record |
Displays the name of the parent record that contains the field GP_VERSION. |
Child Record |
Displays the child record whose data when changed causes GP_VERSION to be cleared from the corresponding row in parent record. (The name of the parent record is displayed here if there are no children.) |
Export Record |
Selected if the child record is to be included in the version package for export and import. For example, when an accumulator element changes, only data in GP_ACCUMULATOR and GP_ACM_MBR needs to be moved. The child record, GP_ACM_MBR_VW, does not need to be exported and imported because it is used only to associate accumulators with earnings and deductions in the Earnings and Deductions components. |
Rule Record in Buffer |
Applicable to accumulators only. Selected if the record that has GP_VERSION is in the component buffer (for example, when an earning accumulator is changed, and needs GP_VERSION cleared). Record GP_ACCUMULATOR is not in the component buffer. Select this check box to prevent the system from looking for the record in RECNAME_RULE_DFN in the component buffer and issue a SQLEXEC instead. The child record that exists in the earnings component is GP_ACM_MBR_VW. |
PIN Number Field |
Displays the name of the PIN_NUM field on the record that needs GP_VERSION cleared. Using the earlier example, the earning accumulator PIN_NUM is contained as PIN_MBR_NUM in the earnings component buffer and PIN_NUM itself contains the earning PIN. So, when updating data for GP_ACCUMULATOR, data for PIN_MBR_NUM value and not PIN_NUM value from the earnings component must be updated. |