Results for “org_unit_code”

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

Overview

IGSBV_ORG_UNIT_LOCATIONS is a read-only database view belonging to the IGS (Student System) product family in Oracle E-Business Suite. The IGS module is documented as obsolete in the ETRM (E-Business Suite Technical Reference Manual) for releases 12.1.1 and 12.2.2, meaning it is a legacy component retained for backward compatibility rather than an actively supported functional area. The view presents a normalized projection of the association between an organizational unit and the physical or logical locations assigned to it. Its documented purpose is stated plainly: "This entity contains the locations associated with the organizational unit."

The view exists primarily to support reporting and integration scenarios in which downstream consumers require a stable, join-friendly interface to organizational unit location data without querying the underlying transactional table directly. Because the view applies a WITH READ ONLY clause, it enforces non-modifiability at the database level, preventing DML through the view and reinforcing its role as a query-only reporting artifact.

Underlying Base Objects

The view is defined over a single documented base object: the table IGS_OR_UNIT_LOC. The ETRM metadata records "none documented" in the referenced base objects field, but the view text itself explicitly identifies the source table and confirms the dependency. The defining SQL is:

SELECT UL.ORG_UNIT_CD       ORG_UNIT_CODE,
       UL.START_DT          START_DATE,
       UL.LOCATION_CD        ORG_UNIT_LOCATION,
       UL.CREATED_BY,
       UL.CREATION_DATE,
       UL.LAST_UPDATED_BY,
       UL.LAST_UPDATE_DATE
FROM   IGS_OR_UNIT_LOC UL
WITH READ ONLY

No joins, filters, or derived expressions are applied. The view is therefore a direct column-aliasing projection of IGS_OR_UNIT_LOC. Notably, the ETRM implementation data states "Not implemented in this database," indicating that in the referenced instance the base table or corresponding object was absent. In practical EBS environments, availability of IGSBV_ORG_UNIT_LOCATIONS depends on whether the IGS Student System schema objects were installed, which is uncommon in standard Financials, Supply Chain, or HR deployments.

Key Columns

• ORG_UNIT_CODE (aliased from ORG_UNIT_CD) — the identifier of the organizational unit to which the location association applies. This is the primary grouping key for reporting by unit.
• START_DATE (aliased from START_DT) — the effective start date of the location association, enabling date-ranged queries and historical reconstruction of unit-location relationships.
• ORG_UNIT_LOCATION (aliased from LOCATION_CD) — the location code assigned to the organizational unit. Together with ORG_UNIT_CODE and START_DATE, it forms the logical key of the association.
• CREATED_BY — the user or process that inserted the underlying row into IGS_OR_UNIT_LOC, following standard EBS who-column conventions.
• CREATION_DATE — the timestamp at which the row was created.
• LAST_UPDATED_BY — the user or process responsible for the most recent modification.
• LAST_UPDATE_DATE — the timestamp of the most recent modification, commonly used for incremental extraction and audit comparisons.

The final four columns are standard Oracle Applications audit columns and support both reconciliation and change-data-capture patterns.

Common Use Cases and Queries

The primary use case is resolving which locations belong to a given organizational unit, typically as a lookup for reporting layers, interfaces, or data warehouse loads. A basic query retrieves all locations for a specified unit:

SELECT org_unit_code,
       org_unit_location,
       start_date
FROM   igsbv_org_unit_locations
WHERE  org_unit_code = :p_org_unit_code
ORDER BY start_date, org_unit_location;

For change tracking against a prior extract, the audit columns are used:

SELECT org_unit_code,
       org_unit_location,
       start_date,
       last_update_date
FROM   igsbv_org_unit_locations
WHERE  last_update_date >= :p_since_date;

A current-effective-list pattern combines unit and date filtering:

SELECT org_unit_code,
       org_unit_location
FROM   igsbv_org_unit_locations
WHERE  org_unit_code = :p_org_unit_code
AND    start_date <= SYSDATE
ORDER BY start_date DESC;

Because the view carries WITH READ ONLY, it is safe to expose to integration accounts that must not modify source data. Consumers should nonetheless verify object existence in the target instance, given the obsolete status of IGS and the ETRM note that the object was not implemented in the documented database.