Results for “pc_node_id”

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

Overview

AHL_PC_NODES_TL is the translation (language) table associated with the base table AHL_PC_NODES_B in the Oracle E-Business Suite Release 12.1.1 and 12.2.2 environments. It resides in the AHL schema, which supports the Complex Maintenance Repair and Overhaul (CMRO) product family. The object is registered in the ETRM repository with a status of VALID and is formally documented as the "Translation table for AHL_PC_NODES_B."

Its functional purpose is to hold the language-dependent, descriptive attributes of production control node records — the text that must be presented to end users in their chosen session language. The base table AHL_PC_NODES_B stores language-independent attributes (numeric identifiers, flags, and structural relationships), while AHL_PC_NODES_TL stores the corresponding translated descriptive text keyed by language. This base/translation pattern (the _B / _TL convention) is a standard Oracle Application Object Library design and is used consistently across EBS modules to support multi-language deployments.

Under the heuristic Data Vault classification mined from the foreign key structure, this table is described as satellite-leaning. In Data Vault modeling terms, a satellite carries descriptive, time-variant attributes that hang off a hub or link. Because AHL_PC_NODES_TL holds descriptive text (DESCRIPTION) and audit attributes attached to a parent key derived from AHL_PC_NODES_B, treating it as a satellite is a reasonable modeling suggestion. Note that in this table the descriptive columns are also language-qualified, so the language component participates directly in the primary key rather than being a simple attribute.

Key Information Stored

The table comprises ten documented columns. The most significant groupings are as follows:

• PC_NODE_ID — the surrogate identifier of the production control node. This column is a foreign key to AHL_PC_NODES_B and forms part of the composite primary key. It is not a business key in its own right; it is the technical linkage to the parent base table.
• LANGUAGE — the language code qualifying the translation row. Together with PC_NODE_ID it forms the business-key candidate AHL_PC_NODES_TL_U1, which is the unique index used to locate a specific translated record.
• DESCRIPTION — the translated descriptive text for the node in the given LANGUAGE. This is the primary payload column and the reason the translation table exists.
• SOURCE_LANG — the language of the source (base) record, used by the translation framework to drive untranslated-row logic and the "source language" fallback behaviour.
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN. These are the standard EBS "Who" columns populated by the framework on insert and update, providing full auditability of translation changes.
• SECURITY_GROUP_ID — the identifier linking the row to the appropriate security group, with a foreign key to FND_SECURITY_GROUPS. This column drives multi-org / multi-security-group data partitioning, restricting which organisations or business groups can see the translation row.

The primary key is AHL_PC_NODES_TL_PK on (PC_NODE_ID, LANGUAGE). The unique index AHL_PC_NODES_TL_U1 on the same column pair confirms that no more than one translation may exist per node per language, which is the canonical guarantee for a translation table.

Common Use Cases and Queries

The dominant use case is retrieving the translated description of a maintenance/production control node for a given user session. A typical query joins the translation table to the base table and filters on language:

• Session-language lookup: a query that selects DESCRIPTION from AHL_PC_NODES_TL joined to AHL_PC_NODES_B on PC_NODE_ID, with the predicate LANGUAGE = USERENV('LANG') or a bind variable for the current session language. This is the pattern used by the forms and OAF pages that render node descriptions.
• Completeness / translation-gap reporting: a query that counts base rows against translation rows per language to identify missing or untranslated nodes. Such a query typically outer-joins AHL_PC_NODES_B to AHL_PC_NODES_TL on PC_NODE_ID and uses WHERE AHL_PC_NODES_TL.PC_NODE_ID IS NULL, optionally grouped by LANGUAGE.
• Multi-language catalogue extraction: a reporting query that extracts all translations (all languages) for a set of nodes, used to produce bilingual documentation, labels, or interface files. All rows for a given PC_NODE_ID can be retrieved by pivoting or aggregating on LANGUAGE.
• Security-scoped reporting: where multi-org partitioning applies, queries join to FND_SECURITY_GROUPS on SECURITY_GROUP_ID to return only rows visible to the caller's security group.
• Change auditing: queries against LAST_UPDATE_DATE and LAST_UPDATED_BY to report translation changes within a period, useful for validating change control.

Related Objects

The following objects are the most significant relationships based on the documented foreign key and primary key structure:

• AHL_PC_NODES_B — the parent base table. The foreign key is AHL_PC_NODES_TL.PC_NODE_ID → AHL_PC_NODES_B. This is the principal join and the source of the surrogate identifier.
• AHL_PC_NODES_TL_PK — the primary key constraint on (PC_NODE_ID, LANGUAGE), enforcing unique identity per node per language.
• AHL_PC_NODES_TL_U1 — the unique index on (PC_NODE_ID, LANGUAGE), the documented business-key candidate.
• FND_SECURITY_GROUPS — referenced by AHL_PC_NODES_TL.SECURITY_GROUP_ID, providing the security group definition used for data partitioning.
• Oracle Application Object Library "Who" infrastructure — the standard EBS audit columns are maintained by the framework, and the translation row lifecycle is managed in conjunction with the TL framework that drives LANGUAGE and SOURCE_LANG.

Because AHL_PC_NODES_TL is a translation child of AHL_PC_NODES_B, any forms, OAF pages, concurrent programs, or custom reports that display production control node descriptions depend on this table, and any extension that adds descriptive text to a node should insert or update here rather than in the base table. DBA-level review should confirm the documented column list, since the ETRM record for AHL_PC_NODES_TL documents ten columns in the 12.2.2 schema, and the object is flagged VALID in the repository.