Search Results customer_jtot_object_code




Overview
Explore in AI Chat

Overview

OKL_CUSTOMER_ACCT_UV is an APPS-owned database view within the Oracle E-Business Suite Release 12.1.1 and 12.2.2 Leasing and Finance Management (OKL) product family. The view is classified as VALID and functions as the user interface view that populates the customer account list of values (LOV) on the Credit Line contract page. Its purpose is to present a consolidated, display-ready list of lessee parties and their associated customer accounts, together with the legal address associated with each account, so that leasing agents can select a valid customer account during credit line setup and contract authoring.

The object is read-only and is not a table; it exposes no data entry capability of its own. Because it is defined against the Trading Community Architecture (TCA) party, account, and site-use views, it should be treated as a reporting and integration access point for customer account information rather than as a source of record. The user search term "cust_acct_number" maps directly to the CUST_ACCT_NUMBER column exposed by this view, which is the account number normally displayed in the credit line LOV.

Underlying Base Objects

The documented base objects referenced by OKL_CUSTOMER_ACCT_UV, as recorded in the ETRM 12.2.2 metadata, are:

  • ARP_ADDR_LABEL_PKG (PACKAGE) — address label formatting utility used in address presentation.
  • OKC_ROLE_SOURCES (SYNONYM) — role source definition supplying the LESSEE role filter and effective-dating criteria.
  • OKX_CUSTOMER_ACCOUNTS_V (VIEW) — the TCA customer account view supplying account identifiers, numbers, names, and party identifiers.
  • OKX_CUST_SITE_USES_V (VIEW) — the customer site use view supplying the legal address description.
  • OKX_PARTIES_V (VIEW) — the TCA party view supplying the customer (lessee) identifier, number, and name.

The OKX_* views are the OKL-facing TCA extraction views. The view joins parties to customer accounts on PARTY_ID, applies an outer join to the legal site use, and restricts rows through OKC_ROLE_SOURCES to parties holding an active LESSEE role (RLE_CODE = 'LESSEE', BUY_OR_SELL = 'S') whose start date is on or before the current date and whose end date is null or on or after the current date.

Key Columns

  • CUSTOMER_ID1 / CUSTOMER_ID2 — Party identifiers for the customer (lessee), sourced from OKX_PARTIES_V.ID1 and ID2.
  • CUSTOMER_NUMBER — The customer/party number used to identify the lessee.
  • CUSTOMER_NAME — The party name of the lessee.
  • CUSTOMER_JTOT_OBJECT_CODE — The JTOT object code associated with the party, used for object-type classification.
  • CUST_ACCT_ID — The customer account identifier from OKX_CUSTOMER_ACCOUNTS_V.ID1.
  • CUST_ACCT_NUMBER — The customer account number displayed in the LOV; this is the column commonly searched as "cust_acct_number".
  • CUST_ACCT_NAME — The descriptive name of the customer account.
  • LEGAL_ADDRESS — The legal site use description, defaulted to a single space via NVL when no legal site exists.
  • PARTY_ID — The party identifier carried on the customer account, supporting joins back to TCA.

Common Use Cases and Queries

Because the view is intended for LOV display, typical usage is to look up an account number for a given lessee or to list all accounts available on the credit line page. The following query retrieves accounts by customer number or account number:

SELECT customer_number, customer_name,
       cust_acct_id, cust_acct_number, cust_acct_name,
       legal_address
FROM   apps.okl_customer_acct_uv
WHERE  cust_acct_number = :p_acct_number;

To list all accounts for a specific lessee, filter on the party identifier:

SELECT cust_acct_number, cust_acct_name, legal_address
FROM   apps.okl_customer_acct_uv
WHERE  customer_id1 = :p_party_id;

In data conversion or reconciliation work, the view is frequently used to validate that a customer account being loaded to a credit line is attached to an active LESSEE role. Note that the role effective-dating filter and the legal address outer join are applied internally, so callers need not re-implement them. Queries should always be issued against the APPS synonym and are read-only.