Search Results text_value2




Overview

HR_SUMMARY_PROCESS_RUN is a VALID database view owned by the APPS schema in Oracle E-Business Suite, registered under the PER (Human Resources) product family. As documented in the ETRM metadata for release 12.2.2, the view holds the details of each template that is run through the GSP (Generic Summary Process). It serves as a filtered, semantically meaningful presentation layer over the HR_SUMMARY table, exposing only those summary rows whose TYPE attribute equals 'PROCESS_RUN'.

In the Oracle EBS architecture, the HR_SUMMARY table is a generic key-value repository used across multiple Human Resources features. Rather than forcing reports, concurrent programs, and integrations to repeatedly filter on the discriminator column, HR_SUMMARY_PROCESS_RUN narrows the result set to process-run records only and maps the generic ID_VALUE, TEXT_VALUE1, TEXT_VALUE2, and FK_VALUE1 columns to more descriptive column names. This makes the view a convenient, self-documenting source for reporting on which templates were executed by the Generic Summary Process, when, and by whom. It is a read-only construct; all inserts and updates are performed against the underlying HR_SUMMARY table.

Underlying Base Objects

The view is defined over a single referenced base object: HR_SUMMARY, which is accessed through a SYNONYM in the APPS schema. The documented view text is:

The relationship is therefore a simple one-to-many projection: every row visible through the view corresponds to exactly one HR_SUMMARY row carrying TYPE = 'PROCESS_RUN'. There is no join, aggregation, or union involved. The WHO columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE) are inherited unchanged from HR_SUMMARY, as is BUSINESS_GROUP_ID, which partitions the data by business group in a multi-organization Human Resources installation. Because the predicate on TYPE is embedded in the view definition, any query against the view automatically excludes summary rows belonging to other feature areas that share the HR_SUMMARY table.

Key Columns

The documented column list exposes a mixture of physical and logically renamed attributes. Note that the view text and the documented column list use different labels for several positions; the descriptive names reflect the intended business meaning of the underlying generic columns.

  • ROW_ID / ROWID — the physical row identifier from HR_SUMMARY, used as the unique row locator.
  • PROCESS_RUN_ID (ID_VALUE) — the identifier of the individual process run recorded in the summary row.
  • BUSINESS_GROUP_ID — the business group that owns the record, supporting multi-organization security and filtering.
  • OBJECT_VERSION_NUMBER — the optimistic locking version number maintained by the underlying table.
  • NAME (TEXT_VALUE1 / TEXT_VALUE2) — textual attributes describing the run, populated from the generic text value columns.
  • TEMPLATE_ID (FK_VALUE1) — the foreign key reference identifying the template that was executed through the Generic Summary Process.
  • PROCESS_TYPE — the classification of the process run associated with the record.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE provide standard EBS WHO audit information.

Common Use Cases and Queries

Typical scenarios include auditing template executions, diagnosing failed or repeated runs, and feeding downstream reporting or integration extracts. Because the view already restricts output to process-run data, queries remain simple. A basic listing of recent runs is:

  • SELECT process_run_id, business_group_id, name, template_id, process_type, last_update_date FROM hr_summary_process_run ORDER BY last_update_date DESC;
  • SELECT process_run_id, template_id, created_by, creation_date FROM hr_summary_process_run WHERE business_group_id = :p_bg_id AND creation_date >= :p_from_date;
  • SELECT template_id, COUNT(*) FROM hr_summary_process_run GROUP BY template_id ORDER BY 2 DESC;

All such queries execute through the APPS schema or a responsibility with the necessary HR security profile. Users should treat the view strictly as a read-only reporting interface and perform maintenance on HR_SUMMARY through supported application APIs.