Understanding Report Data Generation

Using the report data generation process, you can easily read payroll results tables and use this data to populate your own reports.

The report data generation process enables you to create reports that contain:

• Corrective and forwarding retroactivity or a mixture of the two.

• Segmentation, retro-segmentation, and segmentation cancelled by retroactivity.

• Reverse calculations.

• Global Payroll status, indicators, and other technical fields.

• Pay group, pay entity, and payment key changes resulting from corrective retroactivity.

• Calculation results stored in earnings, deductions, balance accumulators, accumulators stored with each calculation, absence daily data, processed positive input, generated positive input, supporting elements stored with each calculation, and specific result tables (writable arrays).

• Multiple selections by process run.

• Data based on a calendar group or a period of time.

• Results from finalized and unfinalized calendars.

• Payees selected from any table at the EMPLID level, adhering to HCM security.

• Appropriate payroll segments.

• Selected elements.

• Any and all slices.

Selecting Payroll Results and Populating Output Tables

After you set up the input and output table details using the Define Report Data page, and map fields and define filters on the Report Data Process Details page, the system completes the following steps to select the payroll results and populate the output tables:

1. Select calendar groups.

2. Select eligible payees using payee lists, group builds, security, and payee filter. If a payee filter was created, it is applied here.

3. Join the payee process status table (GP_PYE_PRC_STAT) and the payee segment status table (GP_PYE_SEG_STAT).

4. Select the original segments. If a process filter was created it is applied here.

5. Insert the original, recalc, prior, and last version/revision segments into the worktable (GP_RPTW_TMP). The worktable now contains rows by payee for selected segments, recalculations, prior segments, and last version/revision segments. If a segment filter was created it is applied here.

6. Join the worktable, the primary input table, and the link table (the additional input table joined with the primary input table) according to the data on the Report Data Process Details page. The results are posted to the output table. Only the results derived from the worktable or the primary input table are populated. If an input filter was created it is applied here.

7. Update the output table with data from the additional input tables.

This diagram illustrates how the system generates the report data Worktable.

This diagram illustrates how the system combines the data in the Worktable with the data from the Primary Input Table and Additional Input Table in the process of generating report data.

Four levels of filters exist: payee, process, segment, and input.

• Payee Filter

  This SQL parameter is used to filter the population. It is applied when the selection is based on a specific record or employment table.

• Process Filter

  This SQL parameter is used to filter the entire process in the original segments only. It can be based on any field in the payee process status or payee segment status tables. For example, "and COUNTRY = 'USA'" selects only U.S. payroll results.

• Segment Filter

  This field parameter is used to create a filter for every step of the process in every segment. It can be based on any field in the payee process status, the payee segment status, or the segment writable array table (if defined in the setup). For example, COMPANY 'GBI' makes a selection on the company GBI if COMPANY is stored in a segment writable array.

• Input Filter

  This SQL filter is defined in the setup for each step used to filter the primary input table, the additional input table joined with the primary input table (the link table), or the worktable. Input filters can be used as a filter or as an additional join condition. For example, "and PRI.CALC_RSLT_VAL>0" selects only the positive results.

When retroactivity is encountered, the method used to store report data depends on the retroactive method encountered. When the forwarding method is used, deltas are forwarded to the first slice in the first segment that matches the pay group, run types, and payment keys. In corrective mode, the deltas are not forwarded.

The Report Data feature manages four kinds of segments:

• Original segments

  Original segments correspond to all segments for version 1 revision 1 (V1R1) for a period. In this kind of segment, there is also a virtual segment. The virtual segment is created when there is corrective retroactivity but the pay group, run type, or payment key of the current period does not match the recalculated period.

• Recalculated segments

  Recalculated segments correspond to all segments other than V1R1 that were created during a calendar group run.

• Prior segments

  Prior segments correspond to the previous version/revision of all recalculated or reversal segments.

• Last version/revision

Here is how the system interprets the following situations:

• If a payee has only one calendar and only one segment, then the payee has one original segment.

• If a payee has one calendar and two segments, then the payee has two original segments.

• If a payee has two calendars and one segment, then the payee has two original segments.

• If a payee has one calendar and one segment for the current period, and retro (forwarding or corrective) back to the twelve previous periods (with the same pay group and payment keys), then the payee has one original segment.

• If a payee has one calendar and one segment for the current period, and forwarding retro back to the twelve previous periods (with the same pay group and two different payment keys), then the payee has two original segments — one active, one inactive.

• If a payee has one calendar and one segment for the current period, and a corrective retro back to the twelve previous periods (with the same pay group and two different payment keys), then the payee has two original segments even if Global Payroll creates only one segment for the current period.

Output tables must be defined to store your selected results. These tables must include the following key structure:

The user-defined parameters are defined when setting up the input filter on the Report Data Process Details page. They must follow this syntax:

%PARM.<function>.<parameter>

Consider the following example using the filter And PRI.STATE in (%PARM.REPORT.STATE) and these parameters:

• REPORT, STATE, CA

• REPORT, STATE, OR

In this example, the generated SQL statement would include: And PRI.STATE IN ('CA','OR'). Below is an example of how you would use these user-defined parameters in the program:

&reportBatch.AddParamChar("REPORT", "STATE", "CA");
&amp_reportBatch.AddParamChar("REPORT", "STATE", "OR");

The batch process provides a public section called "EXTRACT" that can be called by an application engine process that prepares the payroll results for reporting. You must prepare the list of parameters. Then the EXTRACT section generates the SQL requests based on the parameters and executes the requests.

A section called "MAIN" is provided for testing purposes. The MAIN section is used by the delivered run control Validate Report Data. The parameters are managed by the delivered application classes via an object &reportBatch defined at the component level:

import GP_RPT_DATA:ReportDataClasses:*;
Component ReportDataAE &reportBatch;

The application engine is based on the state record GP_RPT_AET and includes the following dedicated temporary tables: GP_RPTC_TMP, GP_RPTO_TMP, GP_RPTE_TMP, GP_RPTS_TMP, and GP_RPTW_TMP.

Below is an example of the batch processing setup:

import GP_RPT_DATA:ReportDataClasses:*;
Component ReportDataAE &reportBatch;
&reportBatch.AddParamChar("EXTPRC", "COUNTRY", "USA");
&reportBatch.AddParamChar("EXTPRC", "NAME", "GP_REPORT");
&reportBatch.AddParamChar("EXTPRC", "TYPE", "P");
&reportBatch.AddParamChar("SELPYE", "SECUR", "Y");
&reportBatch.AddParamChar("SELCAL", "CALGRPID", GP_REGISTER_AET.CAL_RUN_ID);
&reportBatch.AddParamChar("SELCAL", "FROMDT", GP_REGISTER_AET.FROM_DT);
&reportBatch.AddParamChar("SELCAL", "TODT", GP_REGISTER_AET.TO_DT);

The call section name is EXTRACT, and the program ID is GP_EXT_AE.

Below is an example of real-time processing setup:

import GP_RPT_DATA:ReportDataClasses:*;
Component ReportDataReal &report;
Local number &instance;
&report = create ReportDataReal();
&report.AddParamChar("EXTPRC", "COUNTRY", "USA");
&report.AddParamChar("EXTPRC", "NAME", "GP_REPORT");
&report.AddParamChar("EXTPRC", "TYPE", "P");
&report.AddParamChar("SELPYE", "SECUR", "Y");
&report.AddParamChar("SELCAL", "CALGRPID", GP_REGISTER_AET.CAL_RUN_ID);
&report.AddParamDate("SELCAL", "FROMDT", GP_REGISTER_AET.FROM_DT);
&report.AddParamDate("SELCAL", "TODT", DERIVED_GP.TO_DT);
&instance = &report.GetInstance();
&report.ExecuteNow();

/* selection from the output tables (using &instance) can be done here
 in order to display results */

When building a transaction that uses report data, you should follow these guidelines:

• Design one or more temporary tables for transaction purposes using the same key structure as the batch process. The tables are keyed by process instance.

• The user transaction should contain inquiry parameters such as EMPLID or CAL_RUN_ID.

• Create a push button or similar feature to launch a PeopleCode program to access the report data. It should run as follows:

  • The class ReportDataReal is initiated.

  • The PeopleCode transforms the inquiry parameters into report data parameters using the method .AppParamChar/Date/Num().

  • The method .GetInstance() is triggered. This method generates a process instance number using a table designed for report data.

  • The method .ExecuteNow() is triggered.

  • The PeopleCode can then load data from the temporary tables into the page buffers (using, for example, the process instance number returned by method .GetInstance()).

  • The content of the temporary tables must then be deleted using the process instance number.

• If two users run the same transaction simultaneously, the system generates two different process instance numbers.