Many Workforce Intelligence reports rely on collected data, stored in summary tables, in order to run efficiently. You need to collect data from your transaction tables regularly so that the information in your reports is up to date.
You collect the data by running pre-defined concurrent programs, as described below.
For information on concurrent programs, see: Overview of Concurrent Processing
This program creates the organization hierarchies on which HTML reports are based. When you run this program, it collects organization hierarchy structures into the HRI_ORG_PARAMS and HRI_ORG_PARAM_LIST tables to improve reporting performance.
Prior to running the concurrent program, ensure you have one hierarchy marked as the primary hierarchy. If no hierarchy is nominated as the primary hierarchy, BIS Load Organization Hierarchy Summary Table will not pick up your hierarchies.
Add the BIS Load Organization Hierarchy Summary Table concurrent program to a request group using the Request Group window. The request group must be used by the responsibility that runs the concurrent program.
Schedule and run the request group using the Submit Request window.
Attention: After running each BIS Load Organization Hierarchy Summary Table request you are advised to run the system administrator request Gather Schema Statistics for the HRI schema. This will ensure that you gather statistics from the BIS Load Organization Hierarchies request.
There are no parameters for this program.
You must also run this program when there are changes to organization hierarchies and you want to reflect them in your reports. Reports will not display accurate information if you do not run this program periodically to update the summary tables.
You should therefore ensure that the concurrent program is run at regular intervals, for example, every day or every week in order to collect any changed data.
If a system failure occurs, you must restart the program.
This concurrent program collects your organization hierarchy structures into the HRI_ORG_HRCHY_SUMMARY table to improve reporting performance. It will perform a full refresh of all the data.
There are no parameters for this program.
Run the HRI Load All Organization Hierarchy Versions concurrent program at implementation.
You must also run this program when there are changes to organization hierarchies and you want to reflect those changes in your reports. Reports will not display accurate information if you do not run this program periodically to update the summary tables.
You should therefore ensure that the concurrent program is run at regular intervals, for example, every day or every week in order to collect any changed data.
If a system failure occurs, you must restart the program
The HRI Load All Supervisor Hierarchies concurrent program populates the Supervisor Hierarchy Summary Table with current and historic supervisor hierarchy data
Note: The program only collects the relationships between primary assignments in order to structure the supervisor hierarchy.
HRI Load All Supervisor Hierarchies concurrent program has the following parameters:
Full Refresh - Yes / No
If you set Full Refresh to Yes, the program will delete all information previously held in the summary table, and will recalculate the supervisor hierarchy history for the entire collection date range specified (see the Collect From Date / Collect To Date parameters).
If you set Full Refresh to No, the program will delete none of the existing table information. It will update the summary table incrementally with any supervisor hierarchy changes that occurred within the collection date range specified (see the Collect From Date / Collect To Date parameters).
The program runs faster if you set the Full Refresh to No.
The default value of this parameter is Yes the first time the program is run, and No thereafter.
Collect From Date / Collect To Date
These parameters define the start and end dates of the collection range. The program will store any supervisor changes occurring (date effectively) between these dates in the summary table.
This date range initially defaults to be the last five years. Thereafter the Collect From Date defaults to the last Collect To Date and the Collect To Date defaults to the current date
At implementation, run the concurrent request, HRI Load All Supervisor Hierarchies, with the following parameter values:
| Parameter | Implementation Value |
|---|---|
| Collect From Date | The earliest date required for supervisor information (default is five years previous) |
| Collect To Date | The current date (default) |
| Full Refresh | Yes (default) |
After implementation, run the HRI Load All Supervisor Hierarchies concurrent program infrequently in full refresh mode, and frequently in incremental mode to capture and report on supervisor hierarchy changes in your enterprise (see the discussion on Full Refresh, above).
If a system failure occurs, you must restart the program
Loops in the supervisor hierarchy will cause the program to print an error message in the concurrent program log. A loop will occur if, for example, A supervises B, B supervises C, and C supervises A. In this case, the program will enter the person-IDs of the supervisors in the loop in the log.
Corrupt data may also produce error messages in the concurrent program log, for example, where an assignment has two date-tracked records that overlap, as shown in the table below:
Assignment With 2 Date-Tracked Records
| Assignment Number | Start Date | End Date | Organization |
|---|---|---|---|
| 10 | 1 Jan 2000 | 24 Apr 2000 | Organization 1 |
| 10 | 1 Apr 2000 | 31 Dec 2000 | Organization 2 |
In this example, the assignment records overlap on 1st to 24th April. To correct this situation, you should find the correct date of the organization transfer, and update the assignment record. If, for example, the transfer occurred on the 25th April, the data should be corrected to:
Corrected Assignment With 2 Date-Tracked Records
| Assignment Number | Start Date | End Date | Organization |
|---|---|---|---|
| 10 | 1 Jan 2000 | 24 Apr 2000 | Organization 1 |
| 10 | 25 Apr 2000 | 31 Dec 2000 | Organization 2 |
Many reports use Workforce Measurement Values (WMVs), for example, Workforce Losses, Workforce Gains, and Workforce Count. WMVs include headcount and full-time equivalent (FTE) assignment budget values. Calculation and collection of this data could involve repeatedly running FastFormula for each assignment every time a report is run, which is expensive and increases the time taken to display the report.
To reduce the number of times the FastFormula is run, a summary table exists which holds a history of the FTE and headcount WMVs for all assignments over the collection date range. The table ensures you are getting the best possible performance from your reports.
You need to populate the summary table with the WMVs used by your reports. To populate the table, you need to run the concurrent program HRI Load Workforce Measurement Value History.
The HRI Load Workforce Measurement Value History request is not used by all reports; some reports still calculate WMV at the time of running.
The concurrent program HRI Load Workforce Measurement History uses the following parameters:
Full Refresh - Yes / No
If you set Full Refresh to Yes, the program will delete all information previously held in the summary table, and will recalculate the WMV history for all assignments over the entire collection date range specified (see the Collect From Date / Collect To Date parameters). Use this mode the first time you run the program.
If you set Full Refresh to No, the program will delete none of the existing table information. It will update the summary table incrementally with any WMV changes that occurred within the collection date range specified (see the Collect From Date / Collect To Date parameters).
The program will run faster if you set the Full Refresh to No.
The following constraints apply:
If WMVs are updated in the forms interface, the summary table will not reflect this change until you re-run the program, and only if you include the effective date of the correction (not the actual date the correction was made).
The summary table will not reflect historical changes if you run the program in incremental mode.
For example, if the collection date range includes today but does not include last year, the program will not pick up changes made today that update WMVs date-effectively last year.
The program will only transfer corrections to WMV data (as opposed to updates, where historical data is retained) to the summary table when you run the program in full refresh mode.
Due to these constraints you should run the full refresh program weekly or monthly to ensure that the WMV history table is correct. If there are no corrections, deletions, or historical/backdated changes, (for example, if you implement WMVs by a FastFormula only, and do not directly store values for an assignment using the forms interface) running the incremental update at consecutive time periods will keep the table up to date.
The default value of this parameter is Yes the first time you run the program, and No thereafter.
Collect From Date / Collect To Date
This parameter defines the start and end dates of the collection range. The program stores any WMV changes occurring (date effectively) between these dates in the WMV summary table.
This date range initially defaults to be the previous year. Thereafter the Collect From Date defaults to the last Collect To Date and the Collect To Date defaults to the current date.
Collect FTE (Yes / No)
This parameter defines whether or not you wish to collect or update the WMV summary table with Full Time Equivalent values.
The default value for Collect FTE is Yes.
Collect Headcount (Yes/No)
This parameter defines whether or not you wish to collect or update the WMV summary table with Headcount values.
The default value for Collect Headcount is Yes.
On implementation, run the concurrent request HRI Load Workforce Measurement Value History with the following parameters:
| Parameter | Implementation Value |
|---|---|
| Collect From Date | The earliest date required for WMV information. |
| Collect To Date | The current date (default) |
| Full Refresh | Yes (default) |
| Collect FTE | Yes (if FTE is used in reporting) |
| Collect Headcount | Yes (if Headcount is used in reporting) |
Thereafter, Oracle recommends that you run the HRI Load Workforce Measurement Value History concurrent program monthly or weekly to capture and report on workforce measurement value changes in your enterprise (see discussion on Full Refresh below).
If a system failure occurs, you must restart the program.
Some US specific Discoverer workbooks use a 'Vets, EEO, AAP, OSHA, Multi Work Sites' hierarchy. They require information about the current generic hierarchy.
The concurrent program HRI Load All Generic Hierarchy Versions calculates the required data and stores it in the Generic Hierarchy Summary table ready for use by the workbooks. These workbooks will only work if you have set up these generic hierarchies and run this concurrent program.
For further information on HRMS Generic Hierarchies see EEO-1 and VETS-100 Reporting in Oracle HRMS, available on My Oracle Support (formerly MetaLink).
The HRI Load All Generic Hierarchy Versions program collects all generic hierarchies of type "Vets, EEO, AAP, OSHA, Multi Work Sites" (system code FEDREP) across all your business groups. The program stores the data in the Generic Hierarchy Summary table.
The HRI Load All Generic Hierarchy Versions concurrent program has no parameters.
Run the HRI Load All Generic Hierarchy Versions concurrent program at implementation.
You must also run this process when there are changes to the generic hierarchies and you want to reflect those changes in your reports. Reports will not display accurate information if you do not run this process periodically to update the summary tables.
You should therefore run the concurrent program at regular intervals, for example, every day or every week in order to collect any changed data.
If a system failure occurs, you must restart the process.