Results for “country_code”

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

Overview

The POS_COO_LOV view is a database object owned by the APPS schema in Oracle E-Business Suite, delivered as part of the ICX (Oracle iProcurement) product family. Its purpose is narrowly scoped: it exposes a list of territories (countries) in a shape suitable for use as a List of Values (LOV) source. The view is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, indicating it is a supported and intact component of the standard application data model.

Although the name suggests a functional role within iProcurement's "COO" (Country of Origin) processing, the view itself is generically defined. It does not filter, join, or transform data beyond selecting and ordering fields from a single underlying territory lookup. This makes it a thin relational projection rather than a business-logic layer. Such views are commonly referenced by Oracle Forms-based LOVs, by concurrent or OAF-based inquiry screens, and by reporting tools that need a lightweight, pre-shaped source of valid territory values. Because it resides in the APPS schema and is owned by that schema, it inherits the standard Oracle EBS grants and synonyms that allow application modules to query it without direct reference to the base territory object.

Underlying Base Objects

The single documented base object referenced by POS_COO_LOV is FND_TERRITORIES_VL, itself a view. This is the territory validation view shipped with the Oracle Application Object Library (FND) and is the canonical source of country and territory definitions in EBS. FND_TERRITORIES_VL is a translated view that resolves the correct language-specific descriptions from the underlying base tables (FND_TERRITORIES and FND_TERRITORIES_TL), exposing both the short name and the territory code.

Because POS_COO_LOV layers directly over FND_TERRITORIES_VL, any change to a territory's short name or code in the base setup is immediately reflected without additional synchronization. The dependency is a pure SELECT with no WHERE predicate, meaning the view returns every active territory defined in the instance, subject only to the language resolution performed by the underlying translated view. This strict one-to-one dependency is important for support diagnostics: issues with POS_COO_LOV almost always trace back to FND_TERRITORIES_VL or the load of territory data itself.

Key Columns

The view exposes two columns, documented as:

• COUNTRY_SHORT_NAME — the short name of the territory, sourced from TERRITORY_SHORT_NAME in FND_TERRITORIES_VL. This is the user-facing label typically displayed in an LOV, such as "United States" or "Germany."
• COUNTRY_CODE — the territory code, sourced from TERRITORY_CODE. This is the internal identifier used by EBS for validation and joins, generally corresponding to the ISO country code.

The documented view text maps the underlying columns to these output names and orders the result set by TERRITORY_SHORT_NAME, so consumers receive an alphabetically sorted list without needing to specify their own ORDER BY clause. This ordering is a deliberate design choice to support LOV display behavior, where values appear in a predictable, user-friendly sequence.

Common Use Cases and Queries

The view is most often used as a lookup source for country/territory selection in iProcurement flows and in custom reports that require a validated list of countries. A representative query simply selects both columns:

• SELECT country_short_name, country_code FROM apps.pos_coo_lov;
• SELECT country_code, country_short_name FROM apps.pos_coo_lov WHERE country_short_name LIKE :search_term;

Typical scenarios include populating a country-of-origin LOV on a purchasing or sourcing form, validating a user-entered country against the standard territory list, and driving report parameter prompts in Oracle Reports or BI Publisher. Because the view already returns the sorted short name alongside the code, it is convenient for both display and validation. When tuning performance or troubleshooting, note that the view performs no filtering and therefore benefits directly from the indexing and caching characteristics of FND_TERRITORIES_VL; restricting queries with a predicate on the short name reduces the returned row set at the source.