Results for “territory_code”

2 results




Overview
Explore in AI Chat

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

Overview

APPS.TERTORY_VIEW is a simple database view registered in the APPS schema and shipped as part of the GMF — Process Manufacturing Financials product family. Its documented status is VALID across Oracle E-Business Suite 12.1.1 and 12.2.2, and it is described in the ETRM metadata simply as a "Territory view." The object serves as a thin abstraction layer over Oracle's seeded territory reference data, exposing a minimal projection of two columns: TERRITORY_CODE and TERRITORY_SHORT_NAME.

Its practical role is to provide Process Manufacturing Financials components, reports, and integrations with a stable, product-scoped access point for territory identification and display values without requiring those consumers to reference the underlying Foundation (FND) localization view directly. Because it is a view rather than a table, it carries no storage of its own and inherits the security, localization, and translation behaviour of its base object. Users searching for "territory_short_name" will find this view exposing exactly that column, which is the human-readable territory label typically surfaced in list-of-values, report headers, and printed output.

Underlying Base Objects

The view text documented in the ETRM metadata is a single-source SELECT:

The single referenced base object is FND_TERRITORIES_VL, itself a view in the APPS schema. The "_VL" suffix denotes a "view of a translated (language) table" — a standard Oracle EBS construct that unions or filters a base (_B) table against a translation (_TL) table so that short name and description columns are returned in the session's language. TERTORY_VIEW therefore inherits multilingual behaviour transparently: a query issued under a French or German language session returns the corresponding translated territory short name.

No joins, filters, or WHERE clauses are documented in the view definition, so the projection is a straightforward subset of FND_TERRITORIES_VL, restricted to two of the columns exposed by that base view. This makes TERTORY_VIEW one of the simpler reference views in the GMF schema and confirms that it adds naming convenience rather than transformation logic.

Key Columns

  • TERRITORY_CODE — The territory identifier as stored in FND_TERRITORIES. It is the primary key column of the underlying territory entity and is the value typically posted to transactional tables or stored in profile and setup records as the foreign-key reference to a territory.
  • TERRITORY_SHORT_NAME — The short, display-oriented label for the territory, resolved through the translated (_VL) base object. This is the value most commonly rendered in forms, reports, and concurrent program output where a compact, localized territory name is required.

Because the view exposes only these two columns, it is not suitable for lookups requiring territory descriptions, address-validation styles, or other FND_TERRITORIES attributes; those must be sourced from FND_TERRITORIES_VL or FND_TERRITORIES directly.

Common Use Cases and Queries

Typical uses include resolving a stored territory code to its display name on a report, populating a parameter list of values, and validating territory codes during data conversion or inbound interface processing in a Process Manufacturing Financials context.

Resolving a code to its display name:

  • SELECT territory_short_name FROM apps.tertory_view WHERE territory_code = :p_code;

Listing all territories for an LOV or parameter set:

  • SELECT territory_code, territory_short_name FROM apps.tertory_view ORDER BY territory_short_name;

Joining to a transactional or setup table that stores the territory code:

  • SELECT t.territory_code, t.territory_short_name, x.some_amount FROM apps.tertory_view t, apps.some_gmf_table x WHERE x.territory_code = t.territory_code;

Note the non-standard spelling of the object name ("TERTORY" rather than "TERRITORY"), which is the documented identifier and must be used exactly as shown. Consumers should also be aware that localization behaviour is inherited from FND_TERRITORIES_VL, so results are language-dependent and should not be cached across sessions with differing NLS settings.