Results for “agent_type”

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

Overview

The OKL_INSURANCE_AGENT_V view is a standard Oracle E-Business Suite database object owned by the APPS schema and shipped with the OKL – Leasing and Finance Management (ETRM) product family. Its documented purpose is to store and expose Insurance Agent information for use by Oracle Lease and Finance Management applications, reporting tools, and integration interfaces.

Rather than persisting data itself, the view presents a filtered, denormalized projection of Oracle Trading Community Architecture (TCA) party records that qualify as insurance agents. It offers a stable, application-facing contract, insulating downstream OKL functionality from the underlying complexity of the TCA model. The view is listed with a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, and is documented as containing Oracle proprietary and confidential information.

Underlying Base Objects

The view is defined over a single referenced base object, HZ_PARTIES, accessed in the APPS schema through a synonym. The documented view text selects from HZ_PARTIES PRT with two restrictive predicates applied: PRT.CATEGORY_CODE = 'INSURANCE_AGENT' and PRT.STATUS = 'A'.

Consequently, only active parties classified in TCA with the insurance agent category are surfaced. All other HZ_PARTIES records are excluded. The view also introduces two derived, hard-coded columns that are not physical attributes of HZ_PARTIES: a literal '#' aliased as ID2, and a literal 'THIRD_PARTY' alias used to populate the AGENT_TYPE column. These constants support downstream UI or processing logic that expects standard placeholder or classification values.

Key Columns

The view exposes the following columns, most of which map directly to HZ_PARTIES attributes:

• PARTY_ID – The primary TCA identifier for the insurance agent party; the principal join key to other TCA and OKL tables.
• PARTY_NAME – The formatted display name of the party, typically the agent or agency name.
• PARTY_NUMBER – The user-visible unique party number assigned within TCA.
• CATEGORY_CODE – The TCA category; always INSURANCE_AGENT for rows returned by this view.
• STATUS – The party status; always A (active) for rows returned by this view.
• THIRD_PARTY_FLAG – Indicates whether the party is classified as a third party.
• FIRST_NAME, MIDDLE_NAME, LAST_NAME, TITLE, ACADEMIC_TITLE – Person-related name and title attributes, populated for parties of person type. The FIRST_NAME, MIDDLE_NAME, and LAST_NAME columns correspond to the underlying PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, and PERSON_LAST_NAME attributes.
• EMAIL_ADDRESS – The primary e-mail address held for the party in TCA.
• ID2 – A derived column populated with the constant '#'.
• AGENT_TYPE – A derived column populated with the constant 'THIRD_PARTY'.

Common Use Cases and Queries

The view is typically used to populate insurance agent list-of-values (LOV) components, validation routines, and reports within OKL leasing and finance flows, where an insurance agent must be associated with a lease, asset, or insurance policy record. Because it restricts to active insurance agents, it is a convenient source for pick-list and validation queries without requiring application code to re-apply the category and status filters.

To retrieve all active insurance agents:

SELECT party_id,
       party_name,
       party_number,
       email_address,
       agent_type
FROM   apps.okl_insurance_agent_v
ORDER BY party_name;

To look up a specific agent by party number:

SELECT party_id, party_name, email_address
FROM   apps.okl_insurance_agent_v
WHERE  party_number = :p_party_number;

To join agent details to downstream OKL records, the PARTY_ID column is the appropriate join key against TCA-based foreign keys. Reports requiring person-level detail should reference the FIRST_NAME, MIDDLE_NAME, LAST_NAME, and TITLE columns, while agents that are organizations may leave these person attributes null. The derived AGENT_TYPE value 'THIRD_PARTY' should be treated as a fixed classification supplied by the view rather than a stored attribute.