Results for “ahl_relationships_vl”

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

Overview

The view AHL_RELATIONSHIPS_VL is a translated (VL, "view with language") database object owned by the APPS schema in Oracle E-Business Suite. It belongs to the AHL product family, Complex Maintenance Repair and Overhaul (also referred to as Enterprise Asset Management for complex assets), and is available in both the 12.1.1 and 12.2.2 releases. Its role is to present configuration relationship data — the hierarchical parent-child definitions that describe how assemblies, items, and counter items are connected within a maintainable configuration model — while supplying language-translated descriptive text.

Because the view joins the base entity table to its translation table and filters on the session language, it is the standard access point for reports, concurrent programs, Oracle Forms LOVs, and integration interfaces that must display relationship definitions in the user's own language. In ETRM documentation terms, this object carries a VALID status and is a fully supported read interface for reporting against AHL relationship metadata.

Underlying Base Objects

The view text is defined over exactly two base objects, both referenced through APPS synonyms:

• AHL_RELATIONSHIPS_B — the base ("_B") table holding all non-translatable relationship attributes, keyed by RELATIONSHIP_ID. It supplies every column except the translated description.
• AHL_RELATIONSHIPS_TL — the translation ("_TL") table holding language-specific text, also keyed by RELATIONSHIP_ID and LANGUAGE.

The join is an equality on RELATIONSHIP_ID between the two tables, combined with the predicate ART.LANGUAGE = USERENV('LANG'). This restricts the result set to a single row per relationship, expressed in the language of the current database session. The view text also exposes ARB.ROWID as the ROW_ID pseudo-column, and the relationship identifier is not prefixed in the select list, so consumers should treat RELATIONSHIP_ID as the primary logical key.

Multi-language installations can therefore serve multiple language sessions from the same physical rows without duplicating configuration data.

Key Columns

The view projects all major configuration-relationship attributes. The most significant for the reported search term and for general configuration modelling are:

• POSITION_NECESSITY_CODE — indicates the necessity of the child position within its parent, distinguishing mandatory from optional components in the configuration. This is the column most directly associated with the user's search.
• RELATIONSHIP_ID — primary identifier of the relationship and join key to both base tables.
• POSITION_REF_CODE and PARENT_RELATIONSHIP_ID — define the position reference and the self-referencing parent link that establishes the configuration hierarchy.
• NAME and DESCRIPTION — the relationship name and its language-translated descriptive text.
• ITEM_GROUP_ID, COUNTER_GROUP_ID, UOM_CODE, QUANTITY — item grouping, counter grouping, unit of measure, and quantity attributes.
• DISPLAY_ORDER — sequencing of relationships in presentation.
• SIBLING_RULES_FLAG, COUNTER_RULE_FLAG, NODE_STATUS_FLAG, CONFIG_STATUS_CODE — configuration rules and status indicators.
• ACTIVE_START_DATE and ACTIVE_END_DATE — effective dating for the relationship.
• OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF (descriptive flexfield) columns for customer-specific extensions.

Common Use Cases and Queries

Typical usage includes configuration reporting, validation of optional versus mandatory positions, and extraction of relationship hierarchies for integration into manufacturing or maintenance systems. Reporting on necessity is a frequent requirement:

• Listing all optional positions in a configuration: SELECT RELATIONSHIP_ID, NAME, POSITION_NECESSITY_CODE FROM APPS.AHL_RELATIONSHIPS_VL WHERE POSITION_NECESSITY_CODE = 'X';
• Retrieving the full hierarchy: SELECT RELATIONSHIP_ID, PARENT_RELATIONSHIP_ID, POSITION_REF_CODE, NAME FROM APPS.AHL_RELATIONSHIPS_VL ORDER BY PARENT_RELATIONSHIP_ID, DISPLAY_ORDER;
• Filtering by effective dates: SELECT RELATIONSHIP_ID, NAME, ACTIVE_START_DATE, ACTIVE_END_DATE FROM APPS.AHL_RELATIONSHIPS_VL WHERE SYSDATE BETWEEN ACTIVE_START_DATE AND NVL(ACTIVE_END_DATE, SYSDATE + 1);

Because the view enforces the language predicate, no additional translation join is required in report SQL. Queries should always be issued against the APPS synonym and never against the underlying base tables directly, ensuring translated content and consistent privilege handling.