Search Results get_second_noa_code

Overview

GHR_PER_SUM is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Global Human Resources (GHR) product family, specifically the summary and analytical presentation of person, assignment, and element information. Its declared AUTHID CURRENT_USER clause indicates that the package executes with the privileges of the invoking schema rather than the definer, which affects how invoker rights and synonym resolution behave in a multi-schema deployment. The package is documented in ETRM with an API classification of OTHER, distinguishing it from public/private or open-interface APIs; it is intended primarily for internal consumption by Oracle's own forms, concurrent programs, and dependent packages rather than for direct customer extension code.

The business purpose of GHR_PER_SUM is to centralize the retrieval of "extra information" (EI) records and related derivation logic so that a single summary or detail view can surface authoritative values without duplicating query logic across forms. Twenty-one documented procedures and functions comprise the public interface, and the package is referenced by eight other packages, confirming its role as a shared utility layer within the GHR/HRMS stack.

Key Procedures and Functions

The three FETCH procedures form the core of the package's extra-information retrieval capability. FETCH_PEOPLEEI returns person-level extra information for a given person and information type as of an effective date, populating up to thirty information attributes. FETCH_ASGEI performs the equivalent retrieval at assignment level, keyed by assignment identifier. FETCH_POSITIONEI retrieves position-level extra information.

The remaining documented routines are accessor and derivation helpers:

• RETURN_SPECIAL_INFORMATION — resolves special-format or context-sensitive information values.
• GET_GRADE_DETAILS / GET_RETAINED_GRADE_DETAILS / FURTHER_RETAINED_DETAILS_EXIST — grade lookup and detection of further retained-grade records.
• GET_POI_DESC — description for a point of interest.
• GET_DUTY_STATION_DETAILS, GET_ORG_DETAILS, GET_ELEMENT_DETAILS — lookup helpers for duty station, organization, and payroll element metadata.
• GET_STATUS_CODE, GET_DOB_ASGSTAT, GET_CURRENT_EMP_FLAG, GET_ASSIGNMENT_ID — status, date-of-birth/assignment-status, current-employee flag, and assignment identifier resolution.
• GET_ELEMENT_ENTRY_VALUES — returns the input values recorded for a payroll element entry; this is the routine most commonly sought by developers reconstructing element entry data.
• INFO_TYPE_IS_VALID — validates an information type before retrieval.
• GET_WORKFLOW_ID, GET_NOA_CODE, GET_SECOND_NOA_CODE — workflow identifier and notice-of-action code lookups.

Tables Accessed

The package reads and writes through APPS synonyms across several HRMS schemas. Person and assignment context comes from PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F, PER_ASSIGNMENT_EXTRA_INFO, and PER_ASSIGNMENT_STATUS_TYPES. Payroll element data is sourced from PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_ENTRY_VALUES_F, PAY_ELEMENT_TYPES_F, and PAY_INPUT_VALUES_F. Organizational and location detail is drawn from HR_ORGANIZATION_INFORMATION, HR_LOCATION_EXTRA_INFO, GHR_POIS, GHR_DUTY_STATIONS_F, and GHR_LOCALITY_PAY_AREAS_F. Workflow and request linkage uses HR_WORKFLOWS and GHR_PA_REQUESTS. Date-effective (F) tables reinforce the effective-dated retrieval semantics of the FETCH procedures.

Usage Notes

GHR_PER_SUM is normally invoked indirectly. Oracle forms that display person or assignment extra information, and concurrent programs that build HRMS summary extracts, call these procedures rather than issuing direct table queries. Because the package is referenced by eight other packages, customizations should avoid modifying its specification. When custom code must retrieve element entry values, GET_ELEMENT_ENTRY_VALUES is the documented entry point; callers should supply valid identifiers and respect the effective-dating conventions of the underlying PAY and PER tables. As with all non-public APIs, signature changes between 12.1.1 and 12.2.2 are possible and should be verified against the target instance before reuse.