Results for “role_name”

50+ results




Overview
Explore in AI Chat

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

Overview

OKL_CS_PARTIES_TAB_UV is a read-only database view owned by the APPS schema in Oracle Lease and Finance Management (OKL), part of the Oracle E-Business Suite 12.1.1 and 12.2.2 releases. Its documented description is simply "List of Parties." The view consolidates the various party roles that can be attached to a lease or finance contract into a single, uniform result set, exposing them through a common column layout so that callers do not need to query each underlying party view individually.

The view is a UNION of four separate party-oriented views, all of which surface vendor, lessor, guarantor and general party information linked to a contract. Each branch of the union returns the same six columns—CONTRACT_ID, CONTRACT_NUMBER, ROLE_NAME, PTYPE, COMPANY and CUSTOMER_NUMBER—so the consumer sees a denormalized list of parties with their role labels. The ROLE_NAME column is uppercased and re-cased using INITCAP, which normalizes the display of role descriptions regardless of how they are stored in the source views.

Like the underlying *_UV views, OKL_CS_PARTIES_TAB_UV is intended for reporting, analytics and integration rather than for base-table maintenance. It provides a stable, user-facing party list for lease contracts without exposing the complexity of the individual vendor, lessor, guarantor and all-parties views.

Underlying Base Objects

The view is defined over four OKL views, combined with UNION (not UNION ALL), which also means duplicate rows across the branches are eliminated:

Documented ETRM 12.2.2 metadata also lists the following referenced base objects: ARP_ADDR_LABEL_PKG (PACKAGE), FND_GLOBAL (PACKAGE), HR_GENERAL (PACKAGE), OKL_CS_ALL_PARTIES_UV (VIEW), OKL_CS_GUARANTOR_AMOUNT_UV (VIEW), OKL_CS_LESSOR_UV (VIEW) and OKL_CS_VENDORS_UV (VIEW). The package references reflect the dependency chain inherited from the four underlying views: FND_GLOBAL for session and user context, HR_GENERAL for party/person name formatting, and ARP_ADDR_LABEL_PKG for address label formatting used when composing the party records. The view itself is a pure SELECT statement and therefore cannot be used for inserts or updates.

Key Columns

  • CONTRACT_ID — the unique internal identifier of the lease or finance contract to which the party is attached. This is the primary join key back to the contract header tables.
  • CONTRACT_NUMBER — the user-visible contract number, useful for operational reporting without needing to join to the contract header.
  • ROLE_NAME — the role played by the party on the contract (for example lessor, vendor, guarantor). The view applies INITCAP to normalize the case of the stored role name.
  • PTYPE — the party type classification for the row. In the guarantor branch this is sourced from PARTY_TYPE, while the other branches expose their own PTYPE attribute.
  • COMPANY — the organization or company associated with the party record.
  • CUSTOMER_NUMBER — the customer or party number used to identify the trading partner in the receivables/party model.

Common Use Cases and Queries

Typical uses include contract party lists on lease reports, 360-degree contract views, and integration extracts that need every party role on a contract in one result set. A common query filters by contract ID, or by role name where a user has searched for "role_name":

  • List all parties for a given contract: SELECT contract_number, role_name, ptype, company, customer_number FROM okl_cs_parties_tab_uv WHERE contract_id = :contract_id;
  • Find all contracts where a party acts in a specific role: SELECT contract_number, role_name, company FROM okl_cs_parties_tab_uv WHERE UPPER(role_name) = UPPER(:role_name);
  • Count role coverage across contracts: SELECT role_name, COUNT(*) FROM okl_cs_parties_tab_uv GROUP BY role_name ORDER BY role_name;

Because the view applies INITCAP, equality filters should generally be case-insensitive or use the INITCAP form to match reliably. All queries should be run with the APPS schema context or a synonym/APPS-privileged account.