Search Results obj_sic_code

Overview

JTF_PARTIES_V is a CRM Foundation (JTF) view owned by the APPS schema that consolidates party and relationship information for Oracle E-Business Suite releases 12.1.1 and 12.2.2. Its documented purpose is to present "Party (Organization or Group or Person) and relationship information," joining the core party registry to the person, organization, contact, and relationship extensions that describe each party in richer detail.

Functionally, the view resolves three distinct party perspectives into a single row: the party itself (PARTY), the party acting as a contact or subordinate within a relationship (SUB_PARTY), and the object party at the far end of that relationship (OBJ_PARTY). This tri-partite structure allows consumers to report on relationships without writing multi-way joins against the underlying HZ tables. It is used primarily by CRM applications, Oracle Forms-based setups, and custom reporting layers that need a denormalized, read-only presentation of the TCA (Trading Community Architecture) party model.

Underlying Base Objects

The ETRM metadata documents the following referenced base objects, all exposed through APPS-level synonyms:

• HZ_PARTIES — the master registry of persons, organizations, and groups, supplying PARTY_ID, PARTY_NUMBER, PARTY_TYPE, and PARTY_NAME.
• HZ_RELATIONSHIPS — supplies RELATIONSHIP_ID and RELATIONSHIP_CODE, which map to the view's PARTY_RELATIONSHIP_ID and PARTY_RELATIONSHIP_TYPE columns.
• HZ_PERSON_PROFILES — provides person-specific attributes such as KNOWN_AS, PERSON_NAME_PHONETIC, DATE_OF_BIRTH, and PERSONAL_INCOME.
• HZ_ORGANIZATION_PROFILES — provides organization attributes including ORGANIZATION_NAME, ANALYSIS_FY, EMPLOYEES_TOTAL, DUNS_NUMBER, TAX_REFERENCE, and JGZZ_FISCAL_CODE.
• HZ_ORG_CONTACTS — supplies contact-level metadata such as ORG_CONTACT_ID, JOB_TITLE, DECISION_MAKER_FLAG, DEPARTMENT, and RANK.

Each HZ_PARTIES instance is aliased multiple times (PARTY, SUB_PARTY, OBJ_PARTY), and the profile and contact tables are similarly aliased (PERSON_PROFILE_SUB, ORG_PROFILE, ORG_CONT) to correlate the appropriate profile with the correct party alias. The view is therefore a union of joins rather than a simple projection, and its row cardinality is driven by the combination of relationship and party-type conditions.

Key Columns

The column list falls into several logical groupings:

• Primary party identity: PARTY_ID, PARTY_NUMBER, PARTY_TYPE, PARTY_NAME — the principal party on the relationship.
• Sub-party identity: SUB_PARTY.PARTY_ID, SUB_PARTY.PARTY_NUMBER, SUB_PARTY.PARTY_TYPE, and SUB_PARTY person name elements (PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX, PERSON_PRE_NAME_ADJUNCT, PERSON_NAME_PHONETIC, KNOWN_AS).
• Object party identity: OBJ_PARTY.PARTY_ID, OBJ_PARTY.PARTY_NUMBER, OBJ_PARTY.PARTY_NAME, OBJ_PARTY.PARTY_TYPE, OBJ_PARTY.GROUP_TYPE, plus the object party's own person-name elements and SIC_CODE.
• Relationship: PARTY_RELATIONSHIP_ID and PARTY_RELATIONSHIP_TYPE (sourced from HZ_RELATIONSHIPS.RELATIONSHIP_CODE).
• Organization profile: ORGANIZATION_NAME, ANALYSIS_FY, FISCAL_YEAREND_MONTH, EMPLOYEES_TOTAL, CURR_FY_POTENTIAL_REVENUE, NEXT_FY_POTENTIAL_REVENUE, YEAR_ESTABLISHED, INTERNAL_FLAG, PUBLIC_PRIVATE_OWNERSHIP_FLAG, DUNS_NUMBER, JGZZ_FISCAL_CODE, TAX_REFERENCE.
• Contact detail: ORG_CONTACT_ID, JOB_TITLE, JOB_TITLE_CODE, DECISION_MAKER_FLAG, MANAGED_BY, NATIVE_LANGUAGE, OTHER_LANGUAGE_1, OTHER_LANGUAGE_2, REFERENCE_USE_FLAG, RANK, DEPARTMENT_CODE, DEPARTMENT.
• Person profile: DATE_OF_BIRTH, PERSONAL_INCOME, KNOWN_AS (nickname alt).
• Audit: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Because the view encapsulates relationship and profile joins, it is commonly queried to identify the parties associated with a given contact relationship, to enumerate the organization profile attributes for a party, or to drive CRM party-search screens.

SELECT PARTY_ID, PARTY_NUMBER, PARTY_NAME, PARTY_TYPE,
       SUB_PARTY.PARTY_ID, SUB_PARTY.PARTY_NUMBER,
       OBJ_PARTY.PARTY_NAME, PARTY_RELATIONSHIP_TYPE
FROM   APPS.JTF_PARTIES_V
WHERE  PARTY_RELATIONSHIP_TYPE = :p_rel_type
AND    PARTY_ID = :p_party_id;

SELECT PARTY_NAME, ORGANIZATION_NAME, DUNS_NUMBER, JGZZ_FISCAL_CODE
FROM   APPS.JTF_PARTIES_V
WHERE  PARTY_TYPE = 'ORGANIZATION'
AND    PARTY_ID = :p_org_party_id;

Note that the view exposes ROWID for the base PARTY row, which supports updatable contexts where the framework permits. Because JTF_PARTIES_V is a read-only compatibility view defined over the HZ schema, Oracle direction for new development favors querying the underlying HZ_PARTIES, HZ_RELATIONSHIPS, and profile tables directly; existing CRM code continues to reference the view. Queries should filter strongly by PARTY_ID or PARTY_RELATIONSHIP_ID to avoid the cartesian effects inherent in the multi-alias join structure.