Search Results okx_salesreps_v




Overview
Explore in AI Chat

Overview

OKX_SALESREPS_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the OKX product, which provides the Contracts Integration layer used by Oracle's sales and contract management modules. As its description indicates, the view exposes information about sales representatives, consolidating sales-credit and resource data into a single denormalized result set suitable for reporting, lookups, and programmatic access by integrated applications.

The view carries a status of VALID and is defined over two underlying objects. Rather than storing data itself, it joins a sales-representative source against a resource source so that consumers can retrieve representative attributes alongside uniquely identifying resource information. Because it is a view, any changes to the underlying base objects are reflected immediately in query results, and no direct DML is permitted against it.

Underlying Base Objects

The documented view text selects from two referenced objects:

  • JTF_RS_SALESREPS_MO_V — a synonym referenced in the FROM clause (aliased as S), supplying the core sales-representative records including salesrep identifiers, credit type, person and name attributes, status, active dates, and e-mail address.
  • JTF_RS_RESOURCE_EXTNS_VL — the resource extension view (aliased as RES), supplying the RESOURCE_ID and a CATEGORY value.

The two objects are joined on RESOURCE_ID. The join is further constrained so that the resource CATEGORY is restricted to the set: EMPLOYEE, OTHER, PARTY, PARTNER, and SUPPLIER_CONTACT. This restriction ensures that only resources qualifying as valid sales representatives are returned. The dependency on JTF_RS_RESOURCE_EXTNS_VL means the view relies on the resource foundation tables maintained by the JTF (CRM Foundation) module, while the sales-rep attributes originate from the JTF_RS_SALESREPS tables underlying the synonym.

Key Columns

The view projects the following columns:

  • RESOURCE_ID — the unique identifier of the underlying resource, used as the join key and the primary reference for downstream integrations.
  • ORG_ID — the operating unit (organization) to which the sales representative belongs, supporting multi-org reporting and security.
  • SET_OF_BOOKS_ID — the set of books associated with the representative, relevant for financial and accounting context.
  • SALES_CREDIT_TYPE_ID — identifies the sales credit type assigned to the representative.
  • PERSON_ID — the person identifier linked to the sales representative record.
  • NAME — the sales representative's name.
  • DESCRIPTION — projected as a literal NULL in the view definition and therefore always empty.
  • B_STATUS and STATUS — status indicators for the representative; the view exposes both the underlying status value and a status column suitable for filtering.
  • START_DATE_ACTIVE and END_DATE_ACTIVE — the effective active date range for the representative, useful for determining current validity.
  • EMAIL_ADDRESS — the representative's e-mail address.

Common Use Cases and Queries

OKX_SALESREPS_V is typically consumed to validate and display sales-representative information during contract integration and order flows. A frequent requirement is listing active representatives for a specific operating unit:

  • Lookup by resource: retrieve representative details for a known RESOURCE_ID.
  • Active representative listing: filter on STATUS and the active date range to return only currently effective representatives.
  • Operational reporting: join RESOURCE_ID or PERSON_ID to contract and order tables for credit and ownership reporting.

A representative query follows:

  • SELECT RESOURCE_ID, ORG_ID, PERSON_ID, NAME, STATUS, START_DATE_ACTIVE, END_DATE_ACTIVE, EMAIL_ADDRESS FROM APPS.OKX_SALESREPS_V WHERE ORG_ID = :p_org_id AND STATUS = 'A' AND (END_DATE_ACTIVE IS NULL OR END_DATE_ACTIVE >= SYSDATE);

Because the view already restricts resource categories to valid sales-representative types, callers do not need to reapply that filter. Note that DESCRIPTION always returns NULL and should not be relied upon. As with all APPS views, access is governed by standard EBS responsibility and data-security rules.