Search Results child_org_unit_cd




Overview

APPS.IGSBV_ORG_UNIT_HIERARCHIES is a read-only reporting view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, delivered as part of the Student System / Student Information (IGS) product family. The view exposes parent-child relationships between organizational units, providing a flattened representation of the IGS_OR_UNIT_REL hierarchy so that reporting tools, concurrent programs, and integration layers can traverse institutional structures without joining directly to the transactional base table. Because the view is defined with the WITH READ ONLY clause, it is exclusively intended for query and extraction purposes; no DML is permitted against it.

The view is particularly relevant to functional and technical consultants who need to surface hierarchy information — such as a parent organization and its subordinate child organizations — filtered by effective dates. The user search term "parent_start_dt" corresponds directly to the view's PARENT_START_DATE column, which reflects the underlying PARENT_START_DT attribute of the base table.

Underlying Base Objects

Per the documented ETRM metadata, the view is defined over a single object: the base table IGS_OR_UNIT_REL. The view text selects from this table with no joins, aggregations, or filters beyond the read-only constraint. It therefore inherits the row-level content and the standard audit columns of IGS_OR_UNIT_REL, and no additional documented base objects are referenced. Any change or purge performed against IGS_OR_UNIT_REL is immediately visible through the view.

Because the ETRM documentation lists "none documented" for referenced base objects at the metadata level, the authoritative source is the view's own SQL text, which confirms IGS_OR_UNIT_REL as the sole underlying table.

Key Columns

Common Use Cases and Queries

Typical scenarios include institutional hierarchy reporting, org-unit roll-up queries for student records, and integration extracts feeding downstream data warehouses. Effective-date filtering is central, since both parent and child relationships carry their own start dates.

Example — retrieve active parent-child pairs for a given date:

SELECT parent_org_unit_code,
       parent_start_date,
       child_org_unit_code,
       child_start_date
FROM   apps.igsbv_org_unit_hierarchies
WHERE  logical_delete_date IS NULL
AND    parent_start_date <= SYSDATE
AND    (child_start_date IS NULL OR child_start_date <= SYSDATE);

Example — list children for a specific parent:

SELECT child_org_unit_code, child_start_date
FROM   apps.igsbv_org_unit_hierarchies
WHERE  parent_org_unit_code = :parent_code
AND    logical_delete_date IS NULL;

Consultants should always apply the logical_delete_date filter and consider the parent_start_date predicate, as these two conditions most directly determine whether a hierarchy relationship is currently valid.