Results for “poei_information30”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GHR_MT_POSITION_EI_V is a database view owned by the APPS schema within the Oracle E-Business Suite Release 12.1.1 / 12.2.2 environment. It belongs to the GHR — US Federal Human Resources product family and carries a status of VALID in the data dictionary. The view is designed to support the mass transfer "in" and "out" processes that move position-related data between staging areas and the production tables in a US Federal HR implementation. Its name encodes this purpose: the MT segment signals mass transfer, and POSITION_EI_V indicates that the view exposes position extra information — the descriptive flexfield, attribute, and information columns stored against a position.

The view functions as a flattening layer. The staging table used by the mass transfer concurrent programs stores position data in a denormalized, positional fashion: generic columns named INFORMATION1 through INFORMATION50. Each of these numbered columns holds a logically distinct data element whose meaning is determined by position, not by name. GHR_MT_POSITION_EI_V re-labels each positional column with a business-meaningful alias, so that downstream PL/SQL packages and reports can reference POSITION_EXTRA_INFO_ID or POEI_ATTRIBUTE1 directly instead of counting INFORMATION columns. In this role the view is a translation and interoperability layer rather than a standalone reporting object.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view is defined over a single referenced base object: GHR_INTERFACE, which is exposed in the APPS schema as a synonym. All columns projected by the view are derived from that interface table; no joins to position, position extra information, or HR lookup tables are documented in the view definition. This is consistent with the mass transfer architecture, in which GHR_INTERFACE acts as the common staging vehicle for multiple GHR transfer programs and differentiators are carried in generic columns.

Because the view is a thin projection, it inherits the row-level security, indexing, and DML characteristics of GHR_INTERFACE. There is no aggregation, filtering predicate, or DISTINCT clause documented in the view text, so row counts in the view equal the qualifying row counts in the interface table.

Key Columns

• GHR_INTERFACE_ID — sourced from INTERFACE_ID; the primary identifier of the interface row.
• MT_PROCESS_DATE — sourced from PROCESS_DATE; the date the mass transfer program processed or is scheduled to process the record.
• MT_SOURCE — sourced from SOURCE_NAME; identifies the originating source of the transfer.
• MT_EFFECTIVE_DATE — sourced from DATE_FROM; the effective date of the position change.
• MT_NAME, MT_STATUS, MT_PERSON_ID, MT_TABLE_NAME, MT_INFORMATION_TYPE — sourced from INFORMATION1 through INFORMATION5; the transfer descriptor block.
• MT_INTER_BG_TRANSFER — sourced from INFORMATION6; indicates a transfer between business groups.
• POSITION_EXTRA_INFO_ID — sourced from INFORMATION7; the surrogate key of the position extra information record, and the column most directly associated with the user search term.
• POSITION_ID — sourced from INFORMATION8; the position to which the extra information belongs.
• INFORMATION_TYPE — sourced from INFORMATION9; the information type that drives the position extra information structure.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — sourced from INFORMATION10 through INFORMATION13; standard concurrent request audit columns.
• POEI_ATTRIBUTE_CATEGORY and POEI_ATTRIBUTE1 … POEI_ATTRIBUTE20 — sourced from INFORMATION14 through INFORMATION34; the descriptive flexfield attribute segment block for the position extra information record.
• POEI_INFORMATION_CATEGORY and POEI_INFORMATION1 … POEI_INFORMATION15 — sourced from INFORMATION35 onward; the extended information segment block.

Common Use Cases and Queries

The principal use case is troubleshooting and validating a mass transfer run. When a position extra information record fails to transfer, DBAs and functional analysts query this view to inspect the staged values before the transfer program consumes them. The POSITION_EXTRA_INFO_ID column is the natural entry point for such investigations, since it links the staging row back to the position extra information record.

To locate staged rows for a specific position extra information record:

SELECT ghr_interface_id,
       mt_process_date,
       mt_source,
       mt_effective_date,
       position_extra_info_id,
       position_id,
       information_type,
       request_id
  FROM apps.ghr_mt_position_ei_v
 WHERE position_extra_info_id = :p_position_extra_info_id;

To audit all rows staged by a particular concurrent request, including the descriptive flexfield payload:

SELECT ghr_interface_id,
       position_extra_info_id,
       position_id,
       poei_attribute_category,
       poei_attribute1,
       poei_attribute2,
       poei_information_category,
       poei_information1
  FROM apps.ghr_mt_position_ei_v
 WHERE request_id = :p_request_id
 ORDER BY ghr_interface_id;

A third scenario is reconciliation between a transfer batch and the target position extra information table, matching on POSITION_EXTRA_INFO_ID and POSITION_ID to confirm that every staged row was applied. Because the view exposes concurrent program audit columns, it can also be used to determine which request last touched a given interface row when diagnosing repeated or failed transfer attempts.