Results for “location_type_id”

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

Overview

JTF_LOC_TYPES_B is a foundational setup table within the JTF (CRM Foundation) product family of Oracle E-Business Suite, holding the base definitions of location types used throughout CRM and trade management applications. In its documented role, it stores location types such as CITY and STATE, which serve as controlled vocabulary for classifying geographic and address-related entities across the EBS data model. The table resides in the JTF schema and is classified as VALID in the ETRM repository for both 12.1.1 and 12.2.2.

From a Data Vault modeling perspective, the heuristic classification for this object is hub-leaning. That classification reflects the table's function as a business entity registry of location type codes, holding relatively stable reference values that act as a join point for multiple dependent tables. In practical EBS terms, it behaves as a setup or lookup entity rather than a transactional or association table.

Key Information Stored

The documented physical schema for JTF_LOC_TYPES_B contains ten columns. The most important are the surrogate primary key and the business-key candidates:

• LOCATION_TYPE_ID — The surrogate primary key of the table (index JTF_LOC_TYPES_B_PK). It uniquely identifies each location type record and is the column referenced by child tables such as JTF_LOC_TYPES_TL.
• LOCATION_TYPE_CODE — The business-key identifier for the location type (unique index JTF_LOCATION_TYPES_B_UK1). Values include examples such as CITY and STATE. This code is the column most widely referenced by foreign keys into dependent tables.
• SECURITY_GROUP_ID — References FND_SECURITY_GROUPS, supporting multi-tenant or security-restricted access to location type definitions.
• ZD_EDITION_NAME — Part of the unique index JTF_LOC_TYPES_B_U1 (LOCATION_TYPE_ID, ZD_EDITION_NAME), supporting edition-based or versioned data management.

Standard EBS audit and concurrency columns are also present: LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER. Translated or descriptive attributes are not held on this base table; they reside in JTF_LOC_TYPES_TL.

Common Use Cases and Queries

The principal use case is resolving a location type code or ID to its definition, and joining it to dependent tables that classify geographic areas, hierarchies, or location records. A typical query joins the base table to its translation table to retrieve language-specific names:

• Lookup by code: SELECT location_type_id FROM jtf_loc_types_b WHERE location_type_code = 'CITY';
• Translation join: SELECT b.location_type_code, t.description FROM jtf_loc_types_b b, jtf_loc_types_tl t WHERE b.location_type_id = t.location_type_id AND t.language = USERENV('LANG');
• Classifying geography records: joining AMS_ACT_GEO_AREAS on GEO_AREA_TYPE_CODE to identify the type of each activity geography area.
• Reporting on hierarchy definitions by joining JTF_LOC_HIERARCHIES_B on LOCATION_TYPE_CODE.

Because the user searched for "ams_act_geo_areas", the most relevant path is the foreign key from AMS_ACT_GEO_AREAS.GEO_AREA_TYPE_CODE to this table, allowing activity geography areas to be classified by location type.

Related Objects

The following objects depend on or relate to JTF_LOC_TYPES_B through documented foreign keys:

• AMS_ACT_GEO_AREAS — references JTF_LOC_TYPES_B via AMS_ACT_GEO_AREAS.GEO_AREA_TYPE_CODE; classifies activity geography areas by location type.
• JTF_LOC_AREAS_B — references JTF_LOC_TYPES_B via JTF_LOC_AREAS_B.LOCATION_TYPE_CODE.
• JTF_LOC_HIERARCHIES_B — references JTF_LOC_TYPES_B via JTF_LOC_HIERARCHIES_B.LOCATION_TYPE_CODE.
• JTF_LOC_TYPES_TL — references JTF_LOC_TYPES_B via JTF_LOC_TYPES_TL.LOCATION_TYPE_ID; holds translated descriptions.
• FND_SECURITY_GROUPS — referenced by JTF_LOC_TYPES_B.SECURITY_GROUP_ID.

Any extract, migration, or data model analysis touching location classification in CRM Foundation should account for these relationships, since the location type code acts as the pivotal join attribute across the geography and hierarchy tables.