Understanding the Global Payroll Utilities

Global Payroll provides a suite of integrated tools for implementing and maintaining the elements that define your payroll 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 payroll 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 payroll 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 Global Payroll.

• 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 Global Payroll language table (GP_PIN_LANG).

  Doing so can affect your ability to move elements.

• The utilities shouldn't be used during a pay 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.

To move rules and data between databases:

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

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

2. 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:

   1. Define the criteria for creating the package of data to move.

   2. Export the non-rule data and element information from the source database.

   3. Import information for the elements (not the elements themselves) into the target database.

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

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

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:

Related Language Data

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

Related Language Table

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 Global Payroll 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 (for example, if you change only an earning calculation, the element definition itself is not moved).

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

When your application runs on UNIX, exporting and importing packages involves additional considerations if you create data mover scripts on the UNIX machine and run the data mover used for importing and exporting packages via 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.