Search Results contact_email




Overview
Explore in AI Chat

Overview

APPS.CLN_RN_UTIL_TO_ROLE_CUST_SUP_V is a consolidated Oracle E-Business Suite view that presents contact and trading-partner identification information for both customers and suppliers through a single, uniform interface. The view belongs to the CLN (Supply Chain Trading Partner / e-Commerce Gateway) family of objects and is delivered under the APPS schema, where it is exposed to reporting tools, concurrent programs, and integration layers that require a merged picture of trading partner contacts.

Its defining characteristic is a UNION that merges two sibling views — CLN_RN_UTIL_TO_ROLE_CUSTOMER_V and CLN_RN_UTIL_TO_ROLE_SUPPLIER_V — each of which supplies contact rows for one trading partner role. A literal discriminator column, 'C' for customer-sourced rows and 'S' for supplier-sourced rows, is projected as the first column of each branch so that consumers can distinguish the origin of every row after the merge. Because both branches expose an identical eight-column projection, the UNION does not need to reconcile differing column counts or data types, and all columns remain available downstream for filtering, joining, and display.

This view is particularly relevant to integrations that must transmit or display contact details — including the CONTACT_EMAIL attribute that commonly motivates searches against this object — without first determining whether the trading partner is a customer or a supplier. It is a read-only reporting and extraction view rather than a transaction-processing entity.

Underlying Base Objects

The documented base objects and dependencies for this view are:

  • CLN_RN_UTIL_TO_ROLE_CUSTOMER_V (VIEW) — supplies the customer-role branch, tagged with the literal 'C'.
  • CLN_RN_UTIL_TO_ROLE_SUPPLIER_V (VIEW) — supplies the supplier-role branch, tagged with the literal 'S'.
  • FND_GLOBAL (PACKAGE) — the standard EBS session context package referenced by the object's dependency chain, typically for organizational or user context resolution inherited through the underlying views.

The two *_UTIL_TO_ROLE_* views are themselves utility views that map trading partner (TP) records to their role in the customer or supplier domain. Because CLN_RN_UTIL_TO_ROLE_CUST_SUP_V is defined exclusively over views rather than base tables, its row population, join logic, and any role-resolution rules are fully inherited from those two children. Any change to the underlying utility views propagates automatically into this consolidated view, so validation queries should always be traced back to the child views when row counts or contact attributes appear inconsistent.

Key Columns

The view exposes the following columns, in order, with the same shape in both UNION branches:

  • Role indicator (unnamed literal) — 'C' for rows originating from the customer view, 'S' for rows from the supplier view. This is the primary disambiguator for consumers of the merged result set.
  • TP_ID — the trading partner identifier, the primary key that links the row to the trading partner definition.
  • TP_SITE_ID — the trading partner site identifier, scoping the contact to a specific partner location or address.
  • CONTACT_NAME — the name of the contact person or contact record associated with the partner site.
  • CONTACT_EMAIL — the electronic mail address for the contact; a frequently queried attribute for notification, correspondence, and EDI messaging purposes.
  • CONTACT_TELEPHONE — the contact's telephone number.
  • CONTACT_FAX — the contact's facsimile number.
  • EDI_LOCATION_CODE — the Electronic Data Interchange location code used to identify the partner site in EDI transactions.

Common Use Cases and Queries

Typical scenarios include generating consolidated contact directories, validating that email and EDI location data exist before outbound messaging, and feeding downstream notification or gateway processes with a single query.

To retrieve all contacts of a given role:

  • SELECT * FROM APPS.CLN_RN_UTIL_TO_ROLE_CUST_SUP_V WHERE TP_ID = :tp_id;
  • SELECT TP_ID, TP_SITE_ID, CONTACT_NAME, CONTACT_EMAIL FROM APPS.CLN_RN_UTIL_TO_ROLE_CUST_SUP_V WHERE CONTACT_EMAIL IS NOT NULL;
  • SELECT * FROM APPS.CLN_RN_UTIL_TO_ROLE_CUST_SUP_V WHERE EDI_LOCATION_CODE = :loc_code;

Because the leading literal is not aliased in the documented view text, referential queries should select it positionally or wrap the view in an inline subquery that assigns a column alias such as ROLE_TYPE. All access should respect EBS security and MOAC conventions inherited from the underlying utility views.