Export Processing

This topic discusses:

  • Export process flow.

  • Export process details.

  • PI_PARTIC and PI_PARTIC_EXPT tables.

  • PI_EXTIO and PI_PARTIC_EXTBL tables.

  • Export processing and multiple jobs.

This diagram illustrates the Export process flow:

This diagram illustrates the Export process flow.

Payroll Interface Export process flow

Export processing occurs in the following way:

  1. To start the Export process, use the Import/Export Payroll Data (PI_RUNCTL_PNL) component, Import/Export Payroll Data run control page to enter the pay run ID, payroll interface run number, and other parameters.

  2. PI_INRUN reads the pay run ID and run number and calls PIPINRUN.

  3. PIPINRUN calls PIPCMPAR (which in turn calls other subroutines). PIPCMPAR selects, compares, and exports data to tables PI_PARTIC and PI_PARTIC EXPT.

  4. PIPINRUN calls PIXPORT (which in turn calls other subroutines). PIPXPORT reads table PI_PARTIC_EXPT, transfers the changed data to temporary table PI_EXTIO or PI_PARTIC_EXTBL.

  5. PIPINRUN returns control to PI_INRUN.

  6. PI_INRUN calls PI_EXTFL.

  7. If exporting to a file, PI_EXTFL reads the data in PI_EXTIO and creates the export file. If exporting to a table, PI_EXTFL reads the data in PI_PARTIC_EXTBL and creates the export table.

The Export process includes three phases — select, compare, and export:

  • During the select phase, payroll data is retrieved from the PeopleSoft HCM tables.

  • During the compare phase, the selected data is compared against the data from the previous export run.

    The comparison phase identifies any data changes that have occurred since the last export.

  • During the export phase, the data is exported to either a flat file or a table.

A full-records export performs the select and export phases; all data is exported. A changes-only export performs the select, compare, and export phases; only data that has changed is exported.

PI_INRUN calls PIPINRUN

Export processing is based on the pay run ID and run number. For each pay run ID, PIPINRUN retrieves the company and pay group from the pay calendars. The company and pay group are used to verify the payroll interface definitions and to select the employees who will be processed.

PIPINRUN calls PIPCMPAR

First, PIPCMPAR verifies the payroll interface setup for the selected configuration ID:

  1. Using the company and pay group, PIPCMPAR obtains the configuration ID from the Pay Group table.

    Using the configuration ID, it retrieves the file definitions and the system ID from the Configuration table.

    1. For the selected system ID, PIPCMPAR verifies all records and fields in PS Tables table.

    2. For the selected system ID, PIPCMPAR verifies all fields in the Field Definition table.

    3. PICMPAR verifies that all the parameters defined in the Definition table are valid.

  2. Using the company and pay group, PIPCMPAR selects from the Job table all employees (with status values defined in the System table) with a matching company and pay group.

Second, PIPCMPAR performs the actual export process. The export process differs for full-records exports and changes-only exports.

  1. For a full-records export, PIPCMPAR does the following for each selected employee in the pay group:

    1. For each table defined in PS Tables, retrieves rows based on the where clause definition (as well as instance IDs, process IDs, and other information that is set up in the interface).

    2. Exports the results to tables PI_PARTIC and PI_PARTIC_EXPT in the format specified in the Definition table (LOG, PHY, CSV, and so on).

      Note: For full-records exports, all values are considered new, and therefore, changed. Flags in the PI_PARTIC and PI_PARTIC_EXPT tables are initialized to Y and 1.

  2. Changes-only export, PIPCMPAR, does the following for each selected employee in the pay group:

    1. For each table defined in PS Tables, retrieves rows based on the where clause definition (as well as instance IDs, process IDs, and other information that is set up in the interface).

    2. Compares the value of each field (and row, if designated) to the value that was sent in the last export (the previous run number).

    3. Exports the results to table PI_PARTIC and PI_PARTIC_EXPT in the format specified in the Definition table (LOG, PHY, CSV).

      Note: For changes-only exports, flags in the PI_PARTIC and PI_PARTIC_EXPT tables are set to Y and 1 if values change or to N and 0 if values do not change.

PIPINRUN calls PIPXPORT

PIPXPORT reads table PI_PARTIC_EXPT and writes the changed data to temporary table PI_EXTIO or PI_PARTIC_EXTBL.

Note: If no changes occurred, table PI_EXTIO or PI_PARTIC_EXTBL is empty at the end of the export process.

PI_INRUN calls PI_EXTFL

When the export processing is finished, control returns to the Application Engine. PI_INRUN calls PI_EXTFL to create the export file.

PI_EXTFL does the following:

  1. For each row of data in table PI_EXTIO:

    Writes a line to the export file defined in the File Handle table for the file definition. The data is written in the character set defined on the PI System table (LOG, PHY, CSV, and so on).

  2. Deletes the contents of table PI_EXTIO.

  3. Deletes the run control record.

When a full-records or changes-only export is processed, flags are set in the PI_PARTIC and PI_PARTIC_EXPT tables. The values of these flags determine which data is written to the export file (or table).

This diagram illustrates the parent-child relationship between the PI_PARTIC and PI_PARTIC_EXPT tables:

This diagram illustrates the parent-child relationship between the PI_PARTIC and PI_PARTIC_EXPT tables.

Parent-child relationship between the PI_PARTIC and PI_PARTIC_EXPT tables

The PI_PARTIC table contains one row of data for every employee and for every process. It contains high-level information that determines which employees are processed during the comparison phase. Two key fields in this table are EMPLID and PI_RUN_NUM. The PI_RUN_NUM is very important when doing a reprocess run. A critical field on the PI_PARTIC table is PI_CHANGE_IND. If an employee has had a data change since the last Export process, the PI_CHANGE_IND flag is set to Y.

The PI_PARTIC_EXPT table contains the historical (changed) data for the comparison phase. New rows are inserted into this table during each Export process run. Every field that will be sent to the third-party payroll system is in this table. In front of each data element on the PI_PARTIC_EXPT table is a change flag. If the field has changed since the last process, this flag is set to 1; otherwise, it is set to 0. If the field belongs to a group, the data element is prefixed with 2.

Within the PI_PARTIC_EXPT table, the Export Row column is a 250-byte character representation of employee-level data. This data field is the result of information that is set up using the Definition Table (INTRFC_DEFINITION) component. If there is more than 250 bytes of data, another row is inserted into the table and the EXPORT_SEQ is incremented. The export row is positional and is based on the order of the fields that are set up using the Definition Table component. This is very important for maintenance during live processing.

PI_PARTIC Table

If values change, PI_CHANGE_IND is set to Y.

Possible run status indicators for a successful export run are:

Field

Value

PI_PARTIC_STATUS

  • Compared (C). Process is complete.

  • Compare Error (E). An error occurred.

  • In Progress (P). Process is running.

Note: When the process finishes, the flag should be set to C or E. If the flag is set to P, then an error has occurred.

PI_CHANGE_IND

  • Change (Y). Data has changed since the previous export.

  • Process Change (P). Data has changed and caused a process to occur.

  • No Change (N). No data has changed.

Note: Some data changes trigger a process; for example, if an employee is terminated, a stop transaction for deductions may be issued.

PI_CHANGE_TYPE

  • New Hire (N). The employee is a new hire. All data is sent to PI_PARTIC_EXPT.

  • Data (D). Data changed.

  • Process (P). Data has changed and caused a process to occur.

  • Reactive Pay (R). The employee has been rehired.

  • Terminated Pay (T). The employee has been terminated.

  • Blank. No data changed. No data was sent to PI_PARTIC_EXPT.

PI_PARTIC_EXPT Table

If values change, PI_CHANGE_IND is set to Y and the byte-length field flags that are attached to each field value are set to 0, 1, or 2. All exported data is written to EXPORT_ROW, a 250-character field. If the export file is defined at a length greater than 252 characters, then data is loaded into additional EXPORT_ROW fields and the EXPORT_SEQ sequence field is incremented.

Possible run status indicators for a successful export run are:

Field

Value

PI_CHANGE_IND

  • Change (Y). Data has changed. Data fields with a 1 flag will be exported.

  • Process change (P). Data has changed and caused a process to occur.

  • No change (N or blank). No data fields will be exported.

EXPORT_ROW

  • Zero (0). No change.

  • One (1). Change.

  • Two (2). Change in a group field.

Example 1

Assume the following for the employee with EmplID KUI001:

  • Full-records export, run number 1.

  • Data values for salary, union dues, savings bond, and vehicle allowance.

Export

Run Num

Salary

U-Dues

SV-BND

VEH

Full-records

1

1500

10

100

15

PI_PARTIC table—This is a full-records export and all data values are considered changed. PI_CHANGE_IND is set to Y.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

1

PI_CHANGE_IND

Y

PI_PARTIC_EXPT table—PI_CHANGE_IND is set to Y and the byte-length field flag is set to 1 for all data values.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

1

PI_CHANGE_IND

Y

EXPORT_ROW

11500 110 1100 115

Export file—All data values are written to the export file (or table).

Employee (EMPLID)

Salary

U-DUES

SV-BND

VEH

KUI001

1500

10

100

15

Example 2

Assume the following for the employee with EmplID KUI001:

  • Changes-only export, run number 2.

  • Data values for salary and savings bond have changed.

Export

Run Num

Salary

U-Dues

SV-BND

VEH

Full-records

1

1500

10

100

15

Changes-only

2

1800

10

150

15

PI_PARTIC table—PI_CHANGE_IND is set to Y.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

2

PI_CHANGE_IND

Y

PI_PARTIC_EXPT table—PI_CHANGE_IND is set to Y and the byte-length field flag is set to 1 for data values that have changed and to 0 for data values that have not changed.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

2

PI_CHANGE_IND

Y

EXPORT_ROW

11800 010 1150 015

Export file—Changed data values are written to the export file (or table).

Employee (EMPLID)

Salary

U-DUES

SV-BND

VEH

KUI001

1800

150

Example 3

Assume the following for the employee with EMPLID KUI001:

  • Changes-only export, run number 3.

  • No data values have changed.

Export

Run Num

Salary

U-Dues

SV-BND

VEH

Full-records

1

1500

10

100

15

Changes-only

2

1800

10

150

15

Changes-only

3

1800

10

150

15

PI_PARTIC table — PI_CHANGE_IND is set to N.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

3

PI_CHANGE_IND

N

PI_PARTIC_EXPT table — PI_CHANGE_IND is set to N and the byte-length field flag is set to 0 for all field values.

Field

Values

EMPL_ID

KUI001

PI_RUN_NUM

3

PI_CHANGE_IND

N

EXPORT_ROW

01800 010 0150 015

Export file — No data values have changed; no data is written to the export file (or table).

Employee (EMPLID)

Salary

U-DUES

SV-BND

VEH

KUI001

The Export process can write data to either an export file or an export table.

This diagram illustrates exporting data to either a file or table:

This diagram illustrates exporting data to either a file or table.

Exporting data to either a file or table from the PI_EXTIO and PI_PARTIC_EXTBL tables

PI_EXTIO Table

In the PI_EXTIO table, the REC_DATA_PARTIAL field should contain the exact contents of the external file. However, if the record length of the external file exceeds 252 bytes, then the rows in PI_EXTIO are split and the RECDATA_SEQ_NO field is incremented.

PI_PARTIC_EXTBL Table

In the PI_PARTIC_EXTBL table, a row for each changed field is written and the SEQ_NUM field is incremented by 1 unless the field has a group ID assigned to it. For fields with group IDs, the same SEQ_NUM is applied to all fields in the group. For the sequence numbering logic to work properly, you must set up grouped fields correctly. For example, the DED group ID can be used to pair the Deduction Code and Deduction Amount fields. These two fields must adjoin each other on the record; fields without the DED group ID cannot be positioned between them.

See Setting Up the Definition Table.

To export data for an employee with multiple jobs, the following criteria is used:

  • An export record is created for each job that is set up with a Payroll Interface company/pay group.

  • All records that use the employee record number in the key send the appropriate data for that record number.

  • All records that do not contain the employee record number in the key (for example, personal data) send the same information that applies to all export records.

  • All of the employee's jobs are exported, whether the jobs are from the same or different pay groups or the same or different companies.

  • When a concurrent job is added or terminated, it is processed the same way that a single job is added or terminated.

If you define unique IDs by combining the PeopleSoft EMPLID and record (job) number, you create separate employees in the third-party payroll system for each job.

If you use multiple jobs in PeopleSoft HCM, but only want to export a single job through Payroll Interface, you might instead identify a particular job record number for all employees, then create an instance ID attached to the record-mapped-to job, to include only that specific job record number.

Payroll System IDs

You can add another key besides the PeopleSoft EMPLID, the national ID, and the payroll interface employee ID. You can use a view, the multiple national ID field on the personal data pages, or the Payroll Interface existing translation logic. The approach that you choose depends on the third-party payroll requirements.

If you need a single check, create a view to combine the values into one amount for each deduction code. Payroll Interface treats each employee ID or employee record number as a separate row of information. Each job is treated as a separate check. This gives you tremendous flexibility when mapping information to the third-party payroll system.