Search Results sub_location_code

Overview

APPS.IGSBV_SUB_LOCATIONS is a Business Intelligence System (BIS) view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It is registered under the FND Design Data identifier IGS.IGSBV_SUB_LOCATIONS and is delivered with a status of VALID. The view belongs to the Oracle Student System (IGS) product family and describes the relationship between locations that is used to determine geographical equivalence between locations. In practical terms, it exposes the hierarchical mapping between an owning location and one or more sub-locations, together with an indicator identifying which sub-location acts as the default.

Because this is a BIS view rather than a base table, it is intended primarily for reporting, extraction and integration use. Query authors can read the view without needing to reconstruct the join logic between the underlying location tables, and external tools or downstream systems can consume a stable, denormalised projection of the location relationship. The view is read-only; no DML is expected against it.

Underlying Base Objects

Per the documented dependency information, APPS.IGSBV_SUB_LOCATIONS is defined over the base object IGS_AD_LOCATION_REL in the APPS schema. The view therefore inherits its rows directly from the location relationship table and exposes a simplified subset of that table's columns. No other base objects are documented as contributors, and the view itself is not referenced by any database object, confirming its role as a terminal reporting object rather than a dependency of other application logic.

The relationship captured by IGS_AD_LOCATION_REL, and surfaced by the view, expresses the ownership or containment model between locations. Each row represents one owning-location to sub-location pairing, so a single owning location may appear in multiple rows when it has several sub-locations. Conversely, a sub-location may be associated with more than one owning location.

Key Columns

• LOCATION_CODE (VARCHAR2, 10) — The code of the owning location in the relationship. A location may have multiple owning locations. This is the parent side of the mapping.
• SUB_LOCATION_CODE (VARCHAR2, 10) — The code of the sub-location in the relationship. A location may have multiple sub-locations. This is the child side of the mapping and is the column typically filtered or joined when resolving a location to its subordinates.
• DEFAULT_INDICATOR (VARCHAR2) — Indicates whether the sub-location is the default sub-location. The system uses this relationship to determine the default unit attempt examination location for students enrolled in on-campus units: unless otherwise specified, a student's examination location is derived from the unit attempt location's default examination location. Each campus may have a single default examination location, and only Campus locations may have default sub-locations.
• CREATED_BY (NUMBER, 15) — Standard Who column recording the user who created the row.
• CREATION_DATE (DATE) — Standard Who column recording the row creation date and time.
• LAST_UPDATED_BY (NUMBER, 15) — Standard Who column recording the last user to update the row.
• LAST_UPDATE_DATE (DATE) — Standard Who column recording the last update timestamp.

Common Use Cases and Queries

The principal use case is resolving examination locations for on-campus students. Reporting on the default exam location per campus is a direct application of the DEFAULT_INDICATOR column combined with the owning and sub-location codes. A second common use case is validating the completeness of the location hierarchy, for example identifying owning locations that have no sub-locations defined, or campuses that carry more than one row flagged as the default.

A basic extraction of the full relationship set follows the documented query text:

• SELECT LOCATION_CODE, SUB_LOCATION_CODE, DEFAULT_INDICATOR, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM APPS.IGSBV_SUB_LOCATIONS;

To isolate default examination sub-locations only, add a predicate on the indicator column, for example filtering rows where DEFAULT_INDICATOR is set to the value denoting the default. To identify every sub-location belonging to a given owning location, filter on LOCATION_CODE. To identify all owning locations for a given sub-location, filter on SUB_LOCATION_CODE.

When building integrations, note that the view carries only the Who audit columns and the three business columns listed above; any additional attributes of the physical locations must be sourced separately from the location definition tables and joined on the location code. Because the view is not referenced by other database objects, changes to its definition will not cascade into dependent views or packages.